This discusses color printing in a Macintosh application.
Whereas the original eight-color model of QuickDraw was sufficient for printing in color on the ImageWriter II, the introduction of Color QuickDraw has created the need for more sophisticated printing methods.
The first section describes using the eight-color QuickDraw model with the ImageWriter II and ImageWriter LQ drivers. Since the current Print Manager does not support Color GrafPorts, the eight-color model is the only method available for the ImageWriters.
The next section describes a technique that can be used for printing halftone images using PostScript (when it is available). Also described is a device independent technique for sending the PostScript data. This technique can be used on any LaserWriter driver 3.0 or later. It will work with all LaserWriters except the the LaserWriter IISC.
It is very likely that better color support will be added to the Print Manager in the future. Until then, these are the best methods available.
Part 1, ImageWriters
The ImageWriter drivers are capable of generating each of the eight standard colors defined in QuickDraw by the following constants:
whiteColor
blackColor
redColor
greenColor
blueColor
cyanColor
magentaColor
yellowColor
To generate color all you need to do is set the foreground and background colors before you begin drawing (initially they are set to blackColor foreground and whiteColor background). To do this you call the QuickDraw routines ForeColor and BackColor as described in Inside Macintosh. If you are using QuickDraw pictures, make sure you set the foreground and background colors before you call ClosePicture so that they are recorded in the picture. Setting the colors before calling DrawPicture doesn’t work.
The drivers also recognize two of the transfer modes: srcCopy and srcOr. The effect of the other transfer modes is not well defined and has not been tested. It may be best to stay away from them.
Caveats
When printing a large area of more than one color you will encounter a problem with the ribbon. When you print a large area of one color, the printer’s pins pick up the color from the back of the ribbon. When another large area of color is printed, the pins deposit the previous color onto the back of the ribbon. Eventually the first color will come through to the front of the ribbon, contaminating the second color. You can get the same kind of effect if you set, for example, a foreground color of yellow and a background color of blue. The ribbon will pick up the blue as it tries to print yellow on top of it. This problem is partially alleviated in the 2.3 version of the ImageWriter driver by using a different printing technique.
The ribbon goes through the printer rather quickly when printing large areas. When the ribbon comes through the second time the colors don’t look too great.
Part 2, LaserWriters
Using the PostScript ‘image’ Operator to Print Halftones
About ‘image’
The PostScript image operator is used to send Bitmaps or Pixmaps to the LaserWriter. The image operator can handle depths from 1 to 8 bits per pixel. Our current LaserWriters can only image about twenty shades of gray, but the printed page will look like there’s more. Being that the image operator is still a PostScript operator, it expects its data in the form of hexidecimal bytes. The bytes are represented by two ASCII characters(0-9,A-F). The image operator takes these parameters:
width height depth matrix image-data
The first three are the width, height, and depth of the image, and the matrix is the transformation matrix to be applied to the current matrix. See the PostScript Language Reference Manual for more information. The image data is where the actual hex data should go. Instead of inserting the data between the first parameters and the image operator itself, it is better to use a small, PostScript procedure to read the data starting from right after the image operator. For example:
640 480 8 [640 0 0 480 0 0]
{currentfile picstr readhexstring pop}
image
FF 00 FF 00 FF 00 FF 00 ...
In the above example, the width of the image is 640, the height is 480, and the depth is 8. The matrix (enclosed in brackets) is setup to draw the image starting at QuickDraw’s 0,0 (top left of page), and with no scaling. The PostScript code (enclosed in braces) is not executed. Instead, it is passed to the image operator, and the image operator will call it repeatedly until it has enough data to draw the image. In this case, it will be expecting 640*480 bytes. When the image operator calls the procedure, it does the following:
1. Pushes the current file which in this case is the stream of data coming to the LaserWriter over AppleTalk. This is the first parameter to readhexstring.
2. Next picstr is pushed. picstr is a string variable defined to hold one row of hex data. The PostScript to create the picstr is:
/picstr 640 def
3. Now readhexstring is called to fill picstr with data from the current file. It begins reading bytes which are the characters following the image operator.
4. Since readhexstring leaves both the string we want, and a boolean that we don’t want on the stack, we do one pop to kill of the boolean. Now the string is left behind for the image operator to use.
So using the above PostScript code you can easily print an image. Just fill in the width height and depth, and send the hex data immediately following the PostScript code.
Setting Up for ‘image’
Most of the users of this technique are going to want to print a Color QuickDraw PixMap. Although the image command does a lot of the work for you, there are still a couple of tricks that are recommended for performance.
Assume the Maximum Depth
Since the current version of the image operator has a maximum depth of 8 bits/pixel, it is wise to convert the source image to the same depth before imaging. This can be done very simply by using an offscreen GrafPort that is set to 8 bits/pixel, and then using CopyBits to do the depth conversion for you. This will do a nice job of converting lower resolution images to 8 bits/pixel.
Build a Color Table
An 8 bit deep image can only use 256 colors. Since the image that you are starting with is probably color, and the image you get will be grayscale, you need to convert the colors in the source color table into PostScript grayscale values. This is actually easy to do using the Color Manager. First create a table that can hold 512 bytes. This is 2 bytes for each color value from 0 to 255. Since PostScript wants the values in ASCII, you need two characters for each pixel. Now loop through the colors in the color table. Call Index2Color to get the real RGB color for that index, and then call RGB2HSL to convert the RGB color into a luminance value. This value will be expressed as a SmallFract which can then be scaled into a value from 0 to 255. This value should then be converted to ASCII, and stored at the appropriate location in the table. When you are done, you should be able to use a pixel value as an index into your table of PostScript color values. For each pixel in the image, send two characters to the LaserWriter.
Sending the Data
Once you have set up the color table, all that left to do is to loop through all of the pixels, and send their PostScript representation to the LaserWriter. There are a couple of ways to do this. First is to use the low-level Print Manager interface and stream the PostScript using the stdBuf PrCtlCall. Although this seems like it would be the fastest way, the latest version of the LaserWriter driver (5.0) converts all low-level calls to their high level equivalent before executing them. Because of this, the low-level interface is no longer faster than the high level. In an FKEY I have written, I use the high-level Print Manager interface, and send the data via the PostScriptHandle PicComment. This way, I can buffer a large amount of data, before actually sending it. Using this technique, I have been able to image a Mac II screen in about 5 minutes on a LaserWriter Plus, and about 1.5 minutes on a LaserWriter II NTX.
Further Reference:
• QuickDraw
• The Printing Manager
• PostScript Language Reference Manual, Adobe Systems
PR 2 - Device-Independent Printing
Printing
Revised by: March 1988
Written by: Ginger Jernigan May 1987
The Printing Manager was designed to give Macintosh applications a device- independent method of printing, but we have provided device-dependent information, such as the contents of the print record. Due to the large number of printer-type drivers becoming available (even for non-printer devices) device independence is more necessary than ever. What this means to you, as a developer, is that we will no longer be providing (or supporting) information regarding the internal structure of the print record.
We realize that there are situations where the application may know the best method for printing a particular document and may want to bypass our dialogs. Unfortunately, using your own dialogs or not using the dialogs at all, requires setting the necessary fields in the print record yourself. There are a number of problems:
• Many of the fields in the print record are undocumented, and, as we change the internal architecture of the Printing Manager to accommodate new devices, those undocumented fields are likely to change.
• Each driver uses the private, and many of the public, fields in the print record differently. The implications are that you would need intimate knowledge of how each field is used by each available driver, and you would have to set the fields in the record differently depending on the driver chosen. As the number of available printer-type drivers increases, this can become a cumbersome task.
Summary
To be compatible with future printer-like devices, it is essential that your application print in a device-independent manner. Avoid testing undocumented fields, setting fields in the print record directly and bypassing the existing print dialogs. Use the Printing Manager dialogs, PrintDefault and PrValidate to set up the print record for you.
Further Reference:
• The Printing Manager
PR 3 - Document Names and the Printing Manager
Printing
Revised by: March 1988
Written by: Bryan Stearns July 1987
Our compatibility testing for LaserShare (Apple’s LaserWriter spooler) has turned up a number of applications that do not provide the Printing Manager with a document name; although this feature is not required, it is nice for users that share printers.
Some printers (usually those that are shared between many users, like the LaserWriter) can provide the names of the users who are printing and the documents that are being printed to others interested in using the printer.
If the chosen printer uses a document name, the Printing Manager gets the name from the frontmost window’s title. If there is no front window, or if the window’s title is empty, the Printing Manager defaults to “unknown.”
This method was chosen because it works most transparently to applications; however, it won’t work if your application doesn’t display windows when printing (for instance, many applications that use windows for their documents do not open their documents when printing in response to a Finder “Print” command).
As a general solution to this problem, you can put up a window containing a message like “Press –. to cancel printing”, and give it the document’s title. If the window is one that doesn’t have a title bar (like dBoxProc), this title will not be displayed. MacApp takes this approach. If for some reason you don’t want to put up a visible window, you can create a tiny window and hide it behind the menu bar: for instance, global coordinates of (1,1,2,2). Make sure you use a plainDBox, so that no title will be drawn (otherwise, in the unlikely case that a user is using a Macintosh II with two stacked screens, main screen on the bottom, the title might be visible on the upper screen).
Since the Printing Manager checks the name at PrValidate time, call PrValidate after PrCloseDoc and before the next PrOpenDoc, if you want unique names.
A number of applications set the document name in the print record directly. You should not do this because a) not all printers support this field, and b) none are guaranteed to support it in the future. (Apple does not guarantee that internal fields of the Printing Manager’s data structures will remain the same; the Printing Manager is targeted for substantial internal change!)
This Technical Note discusses techniques for optimizing code for printing on the LaserWriter.
Changes since March 1988: Updated the “Printable Paper Area” and “Memory Considerations” sections as well as the printer IDs, moved the error messages from the end of the Note to Technical Note #161, A Printing Loop That Cares…, and removed the “Spool-A-Page/Print-A-Page” section because Technical Note #125, Effect of Spool-A-Page/Print-A-Page on Shared Printers, already thoroughly covers this topic.
Introduction
Although the Printing Manager was originally designed to allow application code to be printer independent, there are some things about the LaserWriter that, in some cases, have to be addressed in a printer dependent way. This Note describes what the LaserWriter can and cannot do, memory considerations, speed considerations, as well as other things you need to watch out for if you want to make your printing more efficient on the LaserWriter.
How To Determine The Currently Selected Printer
With the addition of new picture comments and the PrGeneral procedure, an application should never need to know the type of device to which it is connected. However, some developers feel their application should be able to take advantage of all of the features provided by a particular device, not just those provided by the Printing Manager, and in doing so, these developers produce device-dependent applications, which can produce unpredictable results third-party and new Apple printing devices. For this reason, Apple strongly recommends that you use only the features provided by the Printing Manager, and do not try to use unsupported device features.
Even though there is no supported method for determining a device’s type, there is one method described in the original Inside Macintosh that still works for ImageWriter and LaserWriter printer drivers. This method is not supported, meaning that at some point in the future it will no longer work. If you use this method in your application, it is up to you to weigh the value of the feature against the compatibility risk. The following method works for all ImageWriter, ImageWriter II, and LaserWriter (original, Plus, IInt, IIntx) drivers. Since all new devices released from Apple and third-party developers have their own unique ID, it is up to you to decide what to do with an ID that your application does not recognize.
If you are using the high-level Printing Manager interface, first call PrValidate to make sure you have the correct print record. Look at the high byte of the wdev word in the TPrStl subrecord of the print record. Note that if you have your own driver and want to have your own number, please let DTS know, and DTS can register it.
Following is the current list of printer IDs:
Printer wDev
ImageWriter I, ImageWriter II 1
LaserWriter, LaserWriter Plus, Laser-
Writer IInt, LaserWriter IIntx, and
Personal LaserWriter nt 3
LaserWriter IIsc, Personal LaserWriter sc 4
ImageWriter LQ 5
If you are using the low-level Printing Manager interface, there is no dependable way of getting the wDev information. You should not attempt to determine the device ID when using the low-level Printing Manager interface.
Using QuickDraw With the LaserWriter
When you print to the LaserWriter, all of the QuickDraw calls you make are translated (via QuickDraw bottlenecks) into PostScript®, which is in the LaserWriter ROM. Most of the operations available in QuickDraw are available in PostScript, with a few exceptions. The LaserWriter driver does not support the following:
• XOR and NotXOR transfer modes.
• The grafverb invert.
• _SetOrigin calls within PrOpenPage and PrClosePage calls. Use _OffsetRect instead. (This is fixed in version 3.0 and later of the driver.)
• Regions are ignored. You can simulate regions using polygons or bitmaps. Refer to Technical Note #41, Drawing Into An Off-Screen Bitmap, for how to create off-screen bitmaps.
• Clip regions should be limited to rectangles.
• There is a small difference in character widths between screen fonts and printer fonts. Only the end points of text strings are the same.
What You See Is Not Always What You Get
Unfortunately, what you see on the screen is not always what you get. If you are using standard graphic objects, like rectangles, circles, etc., the object is the same size on the LaserWriter as it is on the screen. There are, however, two types of objects where this is not the case: text and bitmaps.
The earlier noted difference between the widths of characters on the screen and the widths of characters on the printer is due to the difference in resolution. However, to maintain the integrity of line breaks, the driver changes the word and character spacing to maintain the end points of the lines as specified. What this all means is that you cannot count on the positions or the widths of printed characters being exactly the same as they are on the screen. This is why in the original MacDraw®, for example, if one carefully places text and a rectangle and prints it, the text sometimes extends beyond the bounds of the rectangle on the printed page. If an application does its own line layout (i.e., positions the words on the line itself), then it may want to disable the LaserWriter’s line layout routines. To disable these routines, use the LineLayoutOff picture comment described in the LaserWriter Reference Manual and Technical Note #91, Optimizing for the LaserWriter—Picture Comments.
The sole exception to this rule is if an application is running on 128K ROMs or later. The 128K ROM Font Manager supports the specification of fractional pixel widths for screen fonts, increasing the screen to printer accuracy. This fractional width feature is disabled by default. To enable it, an application can use _SetFractEnable, after calling _InitFonts.
Applications can use picture comments to left-, right-, or center-justify text. Only the left, right, or center end points are accurate. If the text is fully justified, both end points are accurate. Technical Note #91, Optimizing for the LaserWriter—Picture Comments, discusses these picture comments.
Memory Considerations
To print to the LaserWriter, you need to make sure that you have enough memory available to load the driver’s code. The best way to do this is to have all the code you need for printing in a separate segment and unload everything else. When you print to the LaserWriter you are only able to print in Draft mode. You are not able to spool (as the ImageWriter does in the standard or high-quality settings), and your print code, data, and the driver code have to be resident in memory.
In terms of memory requirements, there is not any magic number that always works with all printer drivers (including third-party printer drivers) that are available for the Macintosh. To make sure there is enough memory available during print time, you should make your printing code a separate segment and swap out all unwanted code and data before you call _PrOpen.
Printable Paper Area
On the LaserWriter there is a 0.45-inch border that surrounds the printable area of the paper (this is assuming an 8.5” x 11” paper). If you select the “Larger Print Area” option in the Page Setup dialog box, the border changes to 0.25 of an inch. This printable area is different than the available print area of the ImageWriter. An application cannot print a larger area because of the memory PostScript needs to image a page. PostScript takes the amount of memory available in the printer and centers it on the paper, and there is not enough RAM in the LaserWriter to image an entire sheet of paper.
Page Sizes
Many developers have expressed a desire to support page sizes other than those provided by the Apple printer drivers. Even though some devices can physically support other page sizes, there is no way for an application to tell the driver to use this size. With the ImageWriter driver, it is possible to modify certain fields in the print record and expand the printable area of the page. However, each of the Apple drivers implements the page sizes in a different way. No one method works for all drivers. Because of this difference, it is strongly recommended that applications do not attempt to change the page sizes provided in the “Style” dialog box. If your application currently supports page sizes other than those provided by the printer driver, you are taking a serious compatibility risk with future Apple and third-party printer drivers.
Speed Considerations
Although the LaserWriter is relatively fast, there are some techniques an application can use to ensure its maximum performance.
• Try to avoid using the QuickDraw Erase calls (e.g., _EraseRect, _EraseOval, etc.). It takes a lot of time to handle the erase function because every bit (90,000 bits per square inch) has to be cleared. Erasing is unnecessary because the paper does not need to be erased the way the screen does.
• Printing patterns takes time, since the bitmap for the pattern has to be built. The patterns black, white, and all the gray patterns have been optimized to use the PostScript gray scales. If you use a different pattern it works, but it just takes longer than usual. In addition, the patterns in driver version 3.0 are rotated; they are not rotated in version 1.0.
• Try to avoid frequently changing fonts. PostScript has to build each character it needs either by using the drawing commands for the built-in LaserWriter fonts or by resizing bitmaps downloaded from screen fonts on the Macintosh. As each character is built, it is cached (if there’s room), so if that character is needed again PostScript gets if from the cache. When the font changes, the characters have to be built from scratch in the new font, which takes time. If the font is not in the LaserWriter, it takes time to download it from the Macintosh. If the user has the option of choosing fonts, you have no control over this variable; however, if you control which fonts to use, keep this in mind.
• Avoid using _TextBox. It makes calls to _EraseRect, which slows the printer, for every line of text it draws. You might want to use a different method of displaying text (e.g., _DrawString or _DrawText) or write your own version of _TextBox. If an application is currently calling _TextBox, changing to another method of displaying text can improve speed on the order of five to one.
• Because of the way rectangle intersections are determined, if your clip region falls outside of the rPage rectangle, you slow down the printer substantially. By making sure your clip region is entirely within the rPage rectangle, you can get a speed improvement of approximately four to one.
• Do not use spool-a-page/print-a-page as some applications do when printing on the ImageWriter. It slows things down considerably because of all of the preparation that has to be done when a job is initiated. Refer to Technical Note #125, Effect of Spool-A-Page/Print-A-Page on Shared Printers, for more information.
• Using _DrawChar to place every character to print can take a lot of time. One reason, of course, is because it has to go through the bottlenecks for every character that is drawn. The other is that the printer driver does its best to do line layout, making the character spacing just right. If you are trying to position characters and the driver is trying to position characters too, there is conflict, and printing takes much longer than necessary. In version 3.0 of the driver, there are picture comments that turn off the line layout optimization, alleviating some of the problem. Refer to Technical Note #91, Optimizing for the LaserWriter—Picture Comments, for more information.
Clipping Within Text Strings
When clipping characters out of a string, make sure that the clipping rectangle or region is greater than the bounding box of the text you want to clip. The reason is that if you clip part of a character (e.g., a descender), the clipped character has to be rebuilt, which takes time. In addition, because of the difference between screen fonts and printer fonts, chances are that you cannot accurately clip the right characters unless you are running on the 128K ROMs and have fractional pixel widths enabled.
When to Validate the Print Record
To validate the print record, call PrValidate. You need validation to check to see if all of the fields are accurate according to the current printer selected and the current version of the driver. You should call PrValidate when you have allocated a new print record or whenever you need to access information from the print record (i.e., when you get rPage). The routines PrStlDialog and PrJobDialog call PrValidate when they are called, so you do not have to worry about it if you use these calls.
Empty QuickDraw Objects
QuickDraw objects that are empty (i.e., they have no pixels in them) and are filled but not framed, do not print on the ImageWriter and do not show up on the screen; however, on the LaserWriter they are real objects and do print.
Further Reference:
• Inside Macintosh, Volume I, QuickDraw
• Inside Macintosh, Volume II, The Printing Manager
• LaserWriter Reference Manual
• Technical Note M.IM.OffscreenBitMap—
Drawing Into An Off-Screen Bitmap
• Technical Note M.IM.PictComments —
Optimizing for the LaserWriter—Picture Comments
• Technical Note M.IM.Spooler —
Effect of Spool-A-Page/Print-A-Page on Shared Printers
• Technical Note M.IM.PrintLoop —
A Printing Loop That Cares…
• PostScript Language Reference, Adobe Systems, Incorporated
• PostScript Language Tutorial and Cookbook, Adobe Systems, Incorporated
MacDraw is a registered trademark of Claris Corporation.
PostScript is a registered trademark of Adobe Systems, Incorporated.
PR 5 - LaserWriter ROMs Bugs
Printing
Revised by: Ginger Jernigan July 1987
Updated: March 1988
Written by: Ginger Jernigan May 1987
These are LaserWriter bugs that your users may encounter when printing from any Macintosh application. These are for your information; you cannot code around them. The bugs described here occur in the 1.0 and 2.0 LaserWriter ROMs.
To determine which ROMs their LaserWriter contains, users can look at the test page that the LaserWriter prints at start-up time. In addition to other information (detailed in the LaserWriter user’s manual), the ROM version is shown at the bottom of the line graph. The original LaserWriter contained version 1.0 ROMs. The currently shipping LaserWriter and those upgraded to the LaserWriter Plus contain version 2.0 ROMs.
These are some of the problems we know of:
1. If the level of paper in the paper tray is getting low, and the user prints a document that will cause the tray to become empty, a PostScript error may occur. This problem exists in both the 1.0 and 2.0 LaserWriter ROMs and will not be fixed in the next ROM version.
2. If a user prints more than 15 copies of a document, a timeout condition may occur causing the print job to abort. With LaserShare, this problem can occur with as few as 9 copies. This problem is a result of the LaserWriter turning AppleTalk off while it is printing. It doesn’t send out any packets to tell the world it’s still alive while it is printing, so the connection times out after about 2 minutes. This problem exists in both the 1.0 and 2.0 LaserWriter ROMs and will not be fixed in the next ROM version.
3. When printing a document that contains more than 10 patterns, users may receive intermittent PostScript errors. This usually occurs when trying to print a lot of patterns, and a bitmap image on the same page. The code for imaging patterns allocates almost all of the available RAM for itself, so when the bitmap imaging code tries to allocate space, and there isn’t enough (and it doesn’t know how to reclaim memory from the previous operation), a limitcheck error occurs. This problem exists in 2.0 LaserWriter ROMs. It will be improved but not fixed in the next ROM version.
4. If a user chooses US Letter or B5 paper and has a different sized tray in the printer, and prints using manual feed, the LaserWriter will print assuming that the paper being fed manually is the same size as that in the tray. For example, if they have a US letter tray in the LaserWriter and print a document formatted for B5 letter using manual feed, the image will not be centered on the page. The printer assumes that the manually fed paper is also US letter size and prints the image positioned accordingly, despite the driver’s instructions. This is a bug in the Note operator in PostScript, which the driver uses for specifying the US letter and B5 letter paper sizes. The workaround is to tell the user to put an B5 tray in the printer when printing B5 manually. This problem exists in the 1.0 and 2.0 ROMs and will not be fixed in the next ROM version.
By the way, an interesting, but annoying, occurance of this bug happens when manually printing Legal sized documents with the 4.0 LaserWriter driver. When the Larger Print Area option in the style dialog is deselected (which is the default) the driver uses the Note operator to specify the page size. When the user prints the document using manual feed, and has a US letter tray in the printer, the image is shifted up on the page cutting off the top of the image. If you tell the user to turn on the Larger Print Area option in the style dialog, the driver specifies the page size using Legal instead of Note and the image is printed properly.
Further Reference:
• The Printing Manager
• PostScript Language Reference Manual, Adobe Systems
PR 6 - Using Low-Level Printing Calls With AppleTalk ImageWriters
Printing
Revised by: Scott "ZZ" Zimmerman February 1988
Revised by: March 1988
Written by: Ginger Jernigan May 1987
When you use the low-level printer driver to print, you don’t get the benefits of the error checking that is done when you use the high-level Printing Manager. So, if the user prints to an AppleTalk ImageWriter (including an AppleTalk ImageWriter LQ) that is busy printing another job, the driver doesn’t know whether the printer is busy, offline, or disconnected. Because of this, PrError will return (and PrintErr will contain) abortErr.
Since there is no way to tell when you are printing to an AppleTalk ImageWriter, the only workaround for this is to use high-level Printing Manager interface.
Further Reference:
• The Printing Manager
PR 7 - PrGeneral
Printing
Revised by: March 1988
Written by: Ginger Jenigan May 1987
The Printing Manager architecture has been expanded to include a new procedure called PrGeneral. The features described here are advanced, special-purpose features, intended to solve specific problems for those applications that need them. The calls to determine printer resolution introduce a good deal of complexity into the application’s code, and should be used only when necessary.
Version 2.5 (and later) of the ImageWriter driver and version 4.0 (and later) of the LaserWriter driver implement a generic Printing Manager procedure called PrGeneral. This procedure allows the Print Manager to expand in functionality, by allowing printer drivers to implement various new functions. The Pascal declaration of PrGeneral is:
PROCEDURE PrGeneral (pData: Ptr);
The pData parameter is a pointer to a data block. The structure of the data block is declared as follows:
TGnlData = RECORD {1st 8 bytes are common for all PrGeneral calls)
iOpCode : INTEGER; {input}
iError : INTEGER; {output}
lReserved : LONGINT; {reserved for future use}
{more fields here, depending on particular call}
END;
The first field is a 2-byte opcode, iOpCode, which acts like a routine selector. The currently available opcodes are described below.
The second field is the error result, iError, which is returned by the print code. This error only reflects error conditions that occur during the PrGeneral call. For example, if you use an opcode that isn’t implemented in a particular printer driver then you will get a OpNotImpl error.
Here are the errors currently defined:
CONST
noErr = 0; {everything’s hunky}
NoSuchRsl = 1; {the resolution you chose isn’t available}
OpNotImpl = 2; {the driver doesn’t support this opcode}
After calling PrGeneral you should always check PrError. If noErr is returned, then you can proceed. If ResNotFound is returned, then the current printer driver doesn’t support PrGeneral and you should proceed appropriately. See Technical Note #118 for details on checking errors returned by the Printing Manager.
IError is followed by a four byte reserved field (that means don’t use it). The contents of the rest of the data block depends on the opcode that the application uses. There are currently five opcodes used by the ImageWriter and LaserWriter drivers.
The Opcodes
Initially, the following calls are implemented via PrGeneral:
• GetRslData (get resolution data): iOpCode = 4
• SetRsl (set resolution): iOpCode = 5
• DraftBits (bitmaps in draft mode): iOpCode = 6
• noDraftBits (no bitmaps in draft mode): iOpCode = 7
• GetRotn (get rotation): iOpCode = 8
The GetRslData and SetRsl allow the application to find out what physical resolutions the printer supports, and then specify a supported resolution. DraftBits and noDraftBits invoke a new feature of the ImageWriter, allowing bitmaps (imaged via CopyBits) to be printed in draft mode. GetRotn lets an application know whether landscape has been selected. Below is a detailed description of how each routine works.
The GetRslData Call
GetRslData (iOpCode = 4) returns a record that lets the application know what resolutions are supported by the current printer. The application can then use SetRsl (description follows) to tell the printer driver which one it will use. This is the format of the input data block for the GetRslData call:
TGetRslBlk = RECORD {data block for GetRslData call}
iOpCode: Integer; {input; = getRslDataOp}
iError: Integer; {output}
lReserved: LongInt; {reserved for future use}
iRgType: Integer; {output; version number}
XRslRg: TRslRg; {output; range of X resolutions}
YRslRg: TRslRg; {output; range of Y resolutions}
iRslRecCnt: Integer; {output; how many RslRecs follow}
rgRslRec: ARRAY[1..27] OF TRslRec; {output; number filled depends on
printer type}
END;
The iRgType field is much like a version number; it determines the interpretation of the data that follows. At present, a iRgType value of 1 applies both to the LaserWriter and to the ImageWriter.
For variable-resolution printers like the LaserWriter, the resolution range fields XRslRg and YRslRg express the ranges of values to which the X and Y resolutions can be set. For discrete-resolution printers like the ImageWriter, the values in the resolution range fields are zero.
Note: In general, X and Y in these records are the horizontal and vertical directions of the printer, not the document! In landscape orientation, X is horizontal on the printer but vertical on the document.
After the resolution range information there is a word which gives the number of resolution records that contain information. These records indicate the physical resolutions at which the printer can actually print dots. Each resolution record gives an X value and a Y value.
When you call PrGeneral you pass in a data block that looks like this:
Below is the data block returned for the LaserWriter:
Note that all the resolution range numbers happen to be the same for this printer. There is only one resolution record, which gives the physical X and Y resolutions of the printer (300x300).
Below is the data block returned for the ImageWriter.
All the resolution range values are zero, because only discrete resolutions can be specified for this printer. There are four resolution records giving these discrete physical resolutions.
Note that GetRslData always returns the same information for a particular printer type—it is not dependent on what the user does or on printer configuration information.
The SetRsl Call
SetRsl (iOpCode = 5) is used to specify the desired imaging resolution, after using GetRslData to determine a workable pair of values. Below is the format of the data block:
TSetRslBlk = RECORD {data block for SetRsl call}
iOpCode: Integer; {input; = setRslOp}
iError: Integer; {output}
lReserved: LongInt; {reserved for future use}
hPrint: THPrint; {input; handle to a valid print record}
iXRsl: Integer; {input; desired X resolution}
iYRsl: Integer; {input; desired Y resolution}
END;
hPrint should be the handle of a print record that has previously been passed to PrValidate. If the call executes successfully, the print record is updated with the new resolution; the data block comes back with 0 for the error and is otherwise unchanged.
However, if the desired resolution is not supported, the error is set to noSuchRsl and the resolution fields are set to the printer’s default resolution
Note that you can undo the effect of a previous call to SetRsl by making another call that specifies an unsupported resolution (such as 0x0), forcing the default resolution.
The DraftBits Call
DraftBits (iOpCode = 6) is implemented on both the ImageWriter and the LaserWriter. (On the LaserWriter it does nothing, since the LaserWriter is always in draft mode and can always print bitmaps.) Below is the format of the data block:
TDftBitsBlk = RECORD {data block for DraftBits and NoDraftBits calls}
iOpCode: Integer; {input; = draftBitsOp or noDraftBitsOp}
iError: Integer; {output}
lReserved: LongInt; {reserved for future use}
hPrint: THPrint; {input; handle to a valid print record}
END;
hPrint should be the handle of a print record that has previously been passed to PrValidate.
This call forces draft-mode (i.e., immediate) printing, and will allow bitmaps to be printed via CopyBits calls. The virtue of this is that you avoid spooling large masses of bitmap data onto the disk, and you also get better performance.
The following restrictions apply:
• This call should be made before bringing up the print dialogs because it affects their appearance. On the ImageWriter, calling DraftBits disables the landscape icon in the Style dialog, and the Best, Faster, and Draft buttons in the Job dialog.
• If the printer does not support draft mode, already prints bitmaps in draft mode, or does not print bitmaps at all, this call does nothing.
• Only text and bitmaps can be printed.
• As in the normal draft mode, landscape format is not allowed.
• Everything on the page must be strictly Y-sorted, i.e. no reverse paper motion between one string or bitmap and the next. Note that this means you can’t have two or more objects (text or bitmaps) side by side; the top boundary of each object must be no higher than the bottom of the preceding object.
The last restriction is important. If you violate it, you will not like the results. But note that if you want two or more bitmaps side by side, you can combine them into one before calling CopyBits to print the result. Similarly, if you are just printing bitmaps you can rotate them yourself to achieve landscape printing.
The NoDraftBits Call
NoDraftBits (iOpCode = 7) is implemented on both the ImageWriter and the LaserWriter. (On the LaserWriter it does nothing, since the LaserWriter is always in draft mode and can always print bitmaps.) The format of the data block is the same as that for the DraftBits call.
This call cancels the effect of any preceding DraftBits call. If there was no preceding DraftBits call, or the printer does not support draft-mode printing anyway, this call does nothing.
The GetRotn Call
GetRotn (iOpCode = 8) is implemented on the ImageWriter and LaserWriter. Here is the format of the data block:
TGetRotnBlk = RECORD {data block for GetRotn call}
iOpCode: Integer; {input; = getRotnOp}
iError: Integer; {output}
lReserved: LongInt; {reserved for future use}
hPrint: THPrint; {input; handle to a valid print record}
fLandscape: Boolean; {output; Boolean flag}
bXtra: SignedByte; {reserved}
END;
hPrint should be the handle to a print record that has previously been passed to PrValidate.
If landscape orientation is selected in the print record, then fLandscape is true.
How To Use The PrGeneral Opcodes
The SetRsl and DraftBits calls may require the print code to suppress certain options in the Style and/or Job dialogs, therefore they should always be called before any call to the Style or Job dialogs. An application might use these calls as follows:
• Get a new print record by calling PrintDefault, or take an existing one from a document and call PrValidate on it.
• Call GetRslData to find out what the printer is capable of, and decide what resolution to use. Check PrError to be sure the PrGeneral call is supported on this version of the print code; if the error is ResNotFound, you have older print code and must print accordingly. But if the PrError return is 0, proceed:
• Call SetRsl with the print record and the desired resolution if you wish.
• Call DraftBits to invoke the printing of bitmaps in draft mode if you wish.
Note that if you call either SetRsl or DraftBits, you should do so before the user sees either of the printing dialogs.
Further Reference:
• The Printing Manager
PR 8 - PrGeneral Bug
Printing
Revised by: March 1988
Written by: Scott "ZZ" Zimmerman November 1987
This technical note documents a bug in the implementation of the PrGeneral procedure in the LaserWriter driver version 4.0. The bug has to do with the format of the information returned by the GetRslData opcode. This technical note will also describe a workaround for the problem.
One of the opcodes supported by the PrGeneral procedure (Technical Note #128) is named GetRslData. The GetRslData operation initializes a resolution record that is of the following form:
TRslRg = RECORD {used in TGetRslBlk}
iMin: Integer; {0 if printer only supports discrete resolutions}
iMax: Integer; {0 if printer only supports discrete
resolutions}
END;
TRslRec = RECORD {used in TGetRslBlk}
iXRsl: Integer; {a discrete, physical X resolution}
iYRsl: Integer; {a discrete, physical Y resolution}
END;
TGetRslBlk = RECORD {data block for GetRslData call}
iOpCode: Integer; {input; = getRslDataOp}
iError: Integer; {output}
lReserved: LongInt; {reserved for future use}
iRgType: Integer; {output; this declaration is for RgType1}
XRslRg: TRslRg; {output; range of X resolutions}
YRslRg: TRslRg; {output; range of Y resolutions}
iRslRecCnt: Integer; {output; how many RslRecs follow}
rgRslRec: ARRAY[1..27]
OF TRslRec; {output; number used depends on printer type}
END;
The LaserWriter 4.0 implementation has a bug that affects the YRslRg and XRslRg fields of the TGetRslBlk record. The correct values for the fields are:
TGetRslBlk.XRslRg.iMin := 25;
TGetRslBlk.XRslRg.iMax := 1500;
TGetRslBlk.YRslRg.iMin := 25;
TGetRslBlk.YRslRg.iMax := 1500;
Unfortunately, the information returned by the LaserWriter 4.0 version of PrGeneral is:
TGetRslBlk.XRslRg.iMin := 25;
TGetRslBlk.XRslRg.iMax := 25;
TGetRslBlk.YRslRg.iMin := 1500;
TGetRslBlk.YRslRg.iMax := 1500;
The recommended workaround for this problem is to use the PrDrvrVers function (Inside Macintosh II-163) to find out which version of the print driver you are using. If you are using 4.0, modify the resolution data before using it. The following code fragment illustrates this workaround:
When the bug is fixed in a future version of the driver, the CheckRslRecord procedure will no longer have any effect on the resolution record. This will make sure your application gets the correct resolution data no matter which version of the driver is being used.
Further Reference:
• The Print Manager
• Technical Note M.IM.PrGeneral—
PrGeneral
PR 9 - Print Dialogs: Adding Items
Printing
Revised by: March 1988
Written by: Ginger Jernigan November 1986
Lew Rollins
This technical note discusses how to add your own items to the Printing Manager’s dialogs.
When the Printing Manager was initially designed, great care was taken to make the interface to the printer drivers as generic as possible in order to allow applications to print without being device-specific. There are times, however, when this type of non-specific interface interferes with the flexibility of an application. An application may require additional information before printing which is not part of the general Printing Manager interface. This technical note describes a method that an application can use to add its own items to the existing style and job dialogs.
Before continuing, you need to be aware of some guidelines that will increase your chances of being compatible with the printing architecture in the future:
• Only add items to the dialogs as described in this technical note. Any other methods will decrease your chances of survival in the future.
• Do not change the position of any item in the current dialogs. This means don’t delete items from the existing item list or add items in the middle. Add items only at the end of the list.
• Don’t count on an item retaining its current position in the list. If you depend on the Draft button being a particular number in the ImageWriter’s style dialog item list, and we change the Draft button’s item number for some reason, your program may no longer function correctly.
• Don’t use more than half the screen height for your items. Apple reserves the right to expand the items in the standard print dialogs to fill the top half of the screen.
• If you are adding lots of items to the dialogs (which may confuse users), you should consider having your own separate dialog in addition to the existing Printing Manager dialogs.
The Heart
Before we talk about how the dialogs work, you need to know this: at the heart of the printer dialogs is a little-known data structure partially documented in the MacPrint interface file. It’s a record called TPrDlg and it looks like this:
TPrDlg = RECORD {Print Dialog: The Dialog Stream object.}
dlg : DialogRecord; {dialog window}
pFltrProc : ProcPtr; {filter proc.}
pItemProc : ProcPtr; {item evaluating proc.}
hPrintUsr : THPrint; {user’s print record.}
fDoIt : BOOLEAN;
fDone : BOOLEAN;
lUser1 : LONGINT; {four longs reserved by Apple}
lUser2 : LONGINT;
lUser3 : LONGINT;
lUser4 : LONGINT;
iNumFst : INTEGER; {numeric edit items for std filter}
iNumLst : INTEGER;
{... plus more stuff needed by the particular printing dialog.}
END;
TPPrDlg = ^TPrDlg; {== a dialog ptr}
All of the information pertaining to a print dialog is kept in the TPrDlg record. This record will be referred to frequently in the discussion below.
How the Dialogs Work
When your application calls PrStlDialog and PrJobDialog, the printer driver actually calls a routine called PrDlgMain. This function is declared as follows:
FUNCTION PrDlgMain (hprint: THPrint; pDlgInit: ProcPtr): BOOLEAN;
PrDlgMain first calls the pDlgInit routine to set up the appropriate dialog (in Dlg), dialog hook (pItemProc) and dialog event filter (pFilterProc) in the TPrDlg record (shown above). For the job dialog, the address of PrJobInit is passed to PrDlgMain. For the style dialog, the address of PrStlInit is passed. These routines are declared as follows:
FUNCTION PrJobInit (hPrint: THPrint): TPPrDlg;
FUNCTION PrStlInit (hPrint: THPrint): TPPrDlg;
After the initialization routine sets up the TPrDlg record, PrDlgMain calls ShowWindow (the window is initially invisible), then it calls ModalDialog, using the dialog event filter pointed to by the pFltrProc field. When an item is hit, the routine pointed to by the pItemProc field is called and the items are handled appropriately. When the OK button is hit (this includes pressing Return or Enter) the print record is validated. The print record is not validated if the Cancel button is hit.
How to Add Your Own Items
To modify the print dialogs, you need to change the TPrDlg record before the dialog is drawn on the screen. You can add your own items to the item list, replace the addresses of the standard dialog hook and event filter with the addresses of your own routines and then let the dialog code continue on its merry way.
TPrDlg record for you and return a pointer to that record. Then call PrDlgMain directly, passing in the address of your own initialization function. The example code’s initialization function adds items to the dialog item list, saves the address of the standard dialog hook (in our global variable prPItemProc) and puts the address of our dialog hook into the pItemProc field of the TPrDlg record. Please note that your dialog hook must call the standard dialog hook to handle all of the standard dialog’s items.
Note: If you wish to have an event filter, handle it the same way that you do a dialog hook.
Now, here is an example (written in MPW Pascal) that modifies the job dialog. The same code works for the style dialog if you globally replace ‘Job’ with ‘Stl’. Also included is a function (AppendDITL) provided by Lew Rollins (originally written in C, translated for this technical note to MPW Pascal) which demonstrates a method of adding items to the item list, placing them in an appropriate place, and expanding the dialog window’s rectangle.
UnloadSeg(@_DataInit); {remove data initialization code before any allocations}
InitGraf(@thePort);
InitFonts;
FlushEvents(everyEvent,0);
InitWindows;
InitMenus;
TEInit;
InitDialogs(NIL);
InitCursor;
{ call the routine that does printing }
FirstBoxValue := 0; { value of our first additional box }
SecondBoxValue := 0; { value of our second addtl. box }
PrOpen; { Open the Print Manager }
IF PrError = noErr THEN
err := Print { This actually brings up the modified Job dialog }
ELSE BEGIN
{tell the user that PrOpen failed}
END;
PrClose; { Close the Print Manager and leave }
END.
The Lightspeed C Example Program
/* NOTE: Apple reserves the top half of the screen (where the current DITL
items are located). Applications may use the bottom half of the screen to add items, but should not change any items in the top half of the screen. An application should expand the print dialogs only as much as is absolutely necessary.
*/
/* Note: A global search and replace of 'Job' with 'Stl' will produce
code that modifies the style dialogs */
#include <DialogMgr.h>
#include <MacTypes.h>
#include <Quickdraw.h>
#include <ResourceMgr.h>
#include <WindowMgr.h>
#include <pascal.h>
#include <printmgr.h>
#define nil 0L
static TPPrDlg PrtJobDialog; /* pointer to job dialog */
/* This points to the following structure:
struct {
DialogRecord Dlg; (The Dialog window)
ProcPtr pFltrProc; (The Filter Proc.)
ProcPtr pItemProc; (The Item evaluating proc. -- we'll change this)
/* Now comes the part where we patch in our item handler. We have to save
the old item handler address, so we can call it if one of the standard items is hit, and put our item handler's address in pItemProc field of the TPrDlg struct
*/
prPItemProc = (long)PrtJobDialog->pItemProc;
/* Now we'll tell the modal item handler where our routine is */
PrtJobDialog->pItemProc = (ProcPtr)&MyJobItems;
/* PrDlgMain expects a pointer to the modified dialog to be returned.... */
/* invert value of SecondBoxValue and redraw it */
SecondBoxValue ^= 1;
SetCtlValue(itemH,SecondBoxValue);
break;
default: Debugger(); /* OH OH */
} /* switch */
} /* if (myItem > 0) */
else /* chain to standard item handler, whose address is saved in
prPItemProc */
{
CallPascal(theDialog,itemNo,prPItemProc);
}
} /* MyJobItems */
The Rez Source
#include "types.r"
resource 'DITL' (256) {
{ /* array DITLarray: 2 elements */
/* [1] */
{8, 0, 24, 112},
CheckBox {
enabled,
"First Box"
};
/* [2] */
{8, 175, 24, 287},
CheckBox {
enabled,
"Second Box"
}
}
};
Further Reference:
• The Printing Manager
• The Dialog Manager
PR 10 - A Printing Loop That Cares…
Printing
Revised by: Pete “Luke” Alexander October 1990
Written by: Ginger Jernigan September 1987
This Technical Note discusses opening and closing the Printing Manager with calls to _PrOpen and _PrClose as well as how to handle errors at print time.
Changes since October 1989: Added the section on error checking, incorporating the error code descriptions formerly found in Technical Note #72, Optimizing For The LaserWriter—Techniques and an updated version of the information formerly found in Technical Note #118, How To Check and Handle Printing Errors.
Introduction
At one time, Apple recommended that developers call _PrOpen at the beginning of their application and _PrClose at the end, before returning to the Finder. This recommendation was in the ancient past when an application only had to deal with a single printer driver.
As more printer drivers became available, it became important for an application to consider the presence of other applications and how opening and closing the printer driver affected them. The user could open the Chooser at any time and change the current printer driver without the current application’s knowledge. If an application followed the old philosophy and a user changed the current printer driver while running the application, the next time the user attempted to print, the wrong driver would be open, the Printing Manager would not be able to find the necessary resources, and the user would get an error.
The Current Recommendation
DTS currently recommends that applications open and close the printer driver each time the application uses the Printing Manager.
Restore the resource file to the printer driver's.
**/
UseResFile(printmgrsResFile);
thePrPort = PrOpenDoc(thePrRecHdl, nil, nil);
if (PrError() == noErr)
{
/**
Print the range of pages of the document
requested by the user from the Print Job Dialog.
**/
pageNumber = firstPage;
while (pageNumber <= lastPage && PrError() == noErr)
{
PrOpenPage(thePrPort, nil);
if (PrError() == noErr)
{
/**
rPage (IM II-150) is the printable area
for the currently selected printer. By passing the current port to the draw routine, enables your app to use the same routine to draw to the screen and the printer's GrafPort.
**/
DrawStuff ((**thePrRecHdl).prInfo.rPage,
(GrafPtr) thePrPort, pageNumber);
}
PrClosePage(thePrPort);
pageNumber++;
} /** End pageNumber loop **/
}
PrCloseDoc(thePrPort);
} /** End copies loop **/
}
/**
The printing job is being canceled by the request of the
user from the Print Style Dialog or the Print Job Dialog.
PrError will be set to PrAbort to tell the Print Manager to
abort the current printing job.
**/
else
PrSetError (iPrAbort); /** cancel from the job dialog **/
}
else
PrSetError (iPrAbort); /** cancel from the style dialog **/
}
}
if (((**thePrRecHdl).prJob.bJDocLoop == bSpoolLoop) && (PrError() == noErr))
Grab the printing error before you close the Print Manager
and the error disappears.
**/
PrintError = PrError();
PrClose();
/**
You do not want to report any printing errors until you have fallen
through the printing loop. This will make sure that ALL of the Print
Manager's open calls have their corresponding close calls, thereby
enabling the Print Manager to close properly and that all temporary
memory allocations are released.
**/
if (PrintError != noErr)
PostPrintingErrors (PrintError);
}
if (thePrRecHdl != nil)
DisposHandle((Handle) thePrRecHdl);
if (PrintingStatusDialog != nil)
DisposDialog(PrintingStatusDialog);
SetPort(oldPort);
} /** PrintStuff **/
Checking And Handling Printing Errors
An application should always check for error conditions while printing by calling PrError. PrError returns errors from the Printing Manager (and some AppleTalk and OS errors) that occur during printing.
As the example code demonstrates, an application should call PrError after each call to a Printing Manager function or procedure. By consistently checking PrError after each call, the application is able to catch any errors created at print time and report them to a user via a dialog box in a clean and graceful manner.
The following section outlines some general error-handling guidelines.
• You should avoid calling PrError within your pIdle procedure; errors that occur while it is executing are usually temporary and serve only as internal flags for communication within the printer driver—they are not intended for the application. If you absolutely must call PrError within your idle procedure, and an error occurs, never abort printing within the idle procedure itself. Wait until the last called printing procedure returns, then check to see if the error still remains. Attempting to abort printing within an idle procedure is a guarantee of certain death.
• Upon detecting an error after the completion of a printing routine, stop drawing at that point, and proceed to the next procedure to close any previously made open calls. For example, if you detect an error after calling PrOpenDoc, skip to the next PrCloseDoc. Or, if you get an error after calling PrOpenPage, skip to the next PrClosePage and PrCloseDoc. Remember that if you have called PrOpen, then you must call the corresponding PrClose to ensure that printing closes properly and all temporary memory allocations are released and returned to the heap.
• Do not display any alert or dialog boxes to report an error until the end of the printing loop. Once at the end, check for the error again; if there is no error assume that printing completed normally. If the error is still present, then you can alert the user.
This technique is important for two reasons. First, if you display a dialog box in the middle of the printing loop, it could cause errors that can terminate an otherwise normal job. For example, if the printer is an AppleTalk printer, the connection can be terminated abnormally since the driver would be unable to respond to AppleTalk requests received from the printer while the dialog box was waiting for input from the user. If the printer does not hear from the Macintosh with a short period of time (e.g., 30 seconds), it times out, assuming that the Macintosh is no longer there, which results in a prematurely broken connection causing another error to which the application must respond.
In addition, the driver may have already displayed its own dialog box in response to an error. In this instance, the driver posts an error to let the application know that something went wrong and it should abort printing. For example, when the LaserWriter driver detects that the Laser Prep version which has been downloaded to the LaserWriter is different than that with which the user is trying to print, it displays the appropriate dialog box informing the user of the situation and giving him the option of reinitializing the printer. If the user chooses to cancel printing, the driver posts an error to let the application know that it needs to abort, but since the driver has already taken care of the error by displaying a dialog box, the error is reset to zero before the printing loop is complete. The application should check for the error again at the end of the printing loop, and if it still indicates an error, the application can then display the appropriate dialog box.
• If using PrGeneral, be prepared to receive the following errors: NoSuchRsl, OpNotImpl, and resNotFound. In all three cases, the application should be prepared to continue to print without using the features of that particular opcode.
However, in the case of the resNotFound error, it means the current printer driver does not support PrGeneral. This lack of support should not be a problem for an application, but it needs to be prepared to deal with this error. If you receive a resNotFound error from PrError, clear the error with a call to PrSetError(0); otherwise, PrError might still contain this error the next time you check it, which would prevent your application from printing.
Canceling or Pausing the Printing Process
If you install a procedure for handling requests to cancel printing, with an option to pause the printing process, beware of timeout problems when printing to the LaserWriter. Communication between the Macintosh and the LaserWriter must be maintained to prevent a job or a wait timeout. If there is no communication for a period of time (over two minutes), the printer times out and the print job terminates due to a wait timeout. Or, if the print job requires more than three minutes to print, the print job terminates due to a job timeout. Since, there is no good method to determine to what type of printer an application is printing, it is probably a good idea to document the possibility of a LaserWriter timing out for a user who chooses to select “pause” for over two minutes.
Error Messages Created In Print Land…
The Printing Manager reports the error messages covered in this section. If an error that does not belong to the Printing Manager occurs, the Printing Manager puts it into low memory, where it can be retrieved with a call to PrError, and terminates the printing loop, if necessary. As already documented, if you encounter an error in the middle of a printing loop, do not jump out; fall through the loop and let the Printing Manager terminate properly.
Error Code Constant Description
0 noErr No error
128 iPrAbort Abort the printing process
(Command-period)
-1 iPrSavePFil Problem saving print file
-17 controlErr Unimplemented Control call
-27 iIOAbort I/O problems
-108 iMemFullErr Not enough heap space
The following errors are specific to the LaserWriter family:
-4101 Printer not found or closed
-4100 Connection just closed
-4099 Write request too big
-4098 Request already active
-4097 Bad connection refnum
-4096 No free Connect Control Blocks (CCBs) available
-8133 PostScript error occurred during transmission of data to printer. Most often caused by a bug in the PostScript code being downloaded.
-8132 Timeout occurred. This error is returned when no data has been sent to the printer for two minutes. Usually caused by extremely long imaging time.
-8131 Printer not responding: it may have been turned “off.” This error occurs if a user turns off the LaserWriter in the middle of a print job.
The following errors are specific to PrGeneral:
1 NoSuchRsl Requested resolution is not supported
2 OpNotImpl Requested PrGeneral opcode not implemented in the current printer driver.
-192 resNotfound The current printer driver does not support PrGeneral.
The most common error encountered is -4101, which is generated if no LaserWriter is selected. Since this error is so common, it is a good idea to display a dialog box requesting the user to select a printer from the Chooser when this error is encountered.
Further Reference:
• Inside Macintosh, Volume II-145 & V-410, The Printing Manager
• Technical Note M.IM.DevIndPrinting —
Device-Independent Printing
• d e v e l o p, July 1990, Issue 3, “Meet PrGeneral”
PR 11 - Programmatic PostScript Files
Printing
Written by: Matt Deatherage & Hugo Ayala September 1992
This Technical Note discusses how to make the LaserWriter driver, versions 7.0 and later, create PostScript files from your printing loop, and when this is and is not appropriate.
Topics
• Creating PostScript files
• The LaserWriter driver is not a PostScript conversion utility
• Sample functions for creating an appropriate print record
I get to make PostScript files?
Yes, but don’t get too excited yet. The feature we’re about to describe is not applicable in every case where you might want to generate PostScript code, so it’s not a generic solution. Like those standardized tests used to say, “Please read all the directions before marking the page.”
There are definitely situations where forcing the LaserWriter driver to create a PostScript file has advantages. It’s extremely handy for many large, multi-network Macintosh installations that have unique printing needs. It can be handy for people using non-AppleTalk PostScript printers. It’s a very useful capability in this and dozens of other situations.
What it’s not useful for is generic PostScript conversion.
The LaserWriter driver was designed expressly for the purpose of converting QuickDraw calls to PostScript for high-resolution imaging on Apple’s PostScript printers. As the years have gone by, it’s been adapted to things that weren’t part of the original design model (like driving non-Apple PostScript printers). One of the features added in recent years was the capability to dump a PostScript file when printing. This was originally only a debugging feature for the convenience of the engineers working on the driver, but when it was made accessible to users through a hidden dialog item and a not-so-secret key combination, the response was overwhelming. In response, the printing engineers included the capability to pick a PostScript file for output was built into versions 7.0 and later of the driver.
That didn’t change the fact that it was still, at heart, a glorified debugging feature. The PostScript the driver creates is designed expressly for printing. It does not create Encapsulated PostScript files (EPSF format). It doesn’t easily incorporate any PostScript document conventions other than the one it uses for its own benefit. It doesn’t generate PostScript Level 2. It includes large amounts of custom encrypted code to provide TrueType™ font rendering technology on PostScript printers where possible.
It’s important to understand that you can’t change any of this. If you have a strong need to programmatically create files just like the LaserWriter driver would create if you chose the “PostScript file” radio button in the job dialog, this technique is for you. If you need anything more customizable, or more specialized, or in a different format, this Note is not for you. The LaserWriter driver is not and never has been a generic PostScript conversion utility; if you want such capabilities, you must still build them into your application.
How to Do the Deed
The LaserWriter driver stores the PostScript file information in the print record—but not in a format designed for your easy access. To make it print to a PostScript file, you have to set a bit, fill in a vRefNum , a dirID and a pointer to the file name—all inside a private LaserWriter driver structure.
The flag is a bit in the word starting at offset $52 (or 82 decimal) of the print record. This is documented as boolean value f2 of the printer flags record prFlag1. Figure 1 shows a redeclaration of this record with the newly-documented fPSFile bit included.
lwTPrFlag1 = PACKED RECORD
f15: BOOLEAN;
f14: BOOLEAN;
f13: BOOLEAN;
f12: BOOLEAN;
f11: BOOLEAN;
f10: BOOLEAN;
f9: BOOLEAN;
f8: BOOLEAN;
f7: BOOLEAN;
f6: BOOLEAN;
f5: BOOLEAN;
f4: BOOLEAN;
f3: BOOLEAN;
fPSFile: BOOLEAN;
fLstPgFst: BOOLEAN;
fUserScale: BOOLEAN;
END;
Figure 1—Redefined PrFlag1 Record
Note that the record is renamed beginning with lw to emphasize that this technique only works with the LaserWriter driver. This means you have to check that you’re printing to the LaserWriter driver by making sure the high byte of TPRStl.wDev is 3, for the LaserWriter driver. If other drivers impersonate the LaserWriter driver (which they may do, for example, so that your application sends them PostScript in picture comments), this may crash. Unfortunately, Apple can’t conclusively tell you that a third-party printer driver will or will not support this feature. Apple’s driver does.
Where does the LaserWriter driver put the new PostScript file? The word starting at offset $68 (104 decimal) is the vRefNum for the file to save, and the long at offset $70 is the directory ID for where to store the file. The long starting at $6A (or 106 decimal in the print record) is a pointer to the PostScript file name as a Pascal string—just the file name; the other fields indicate the other portions of the file’s specification (in fact, they’re all three portions of an FSSpec record).
However, the name pointer isn’t just any old pointer. There’s some baggage with it.
First, the LaserWriter driver always assumes that it allocated the pointer, and somewhere in the printing loop, when it’s done with the PostScript file name, it calls DisposPtr on that pointer. That means you must allocate it with NewPtr and it must be valid during the print loop, or your heap becomes toast. It should be a 64-byte pointer, because the driver assumes that’s what it is.
Second, the LaserWriter driver assumes that it’s the only one who would be messing with this private field in the print record, so it only clears it during PrJobInit. That means when you're done printing, your print record will still contain a pointer to the memory that used to point to the file name string. If you save this print record and try to print again without going through the job dialog, the LaserWriter driver will use it as a pointer on your behalf, even though it probably doesn’t point to anything useful anymore. Also, if the pointer is non-NIL entering the job dialog (if somehow someone bypasses PrJobInit), it also assumes it’s a pointer and uses it. So, before you save or use this print record for anything, always zero the file name pointer. It will save many hassles down the road.
Third, if you encounter a print record that has the fPSFile bit (bit 3 of offset $52) already set, the LaserWriter driver has already validated the information in the print record. The pointer has been allocated and the directory information stored. Do not override these values or you may cause a memory leak.
The driver also saves in the print record, in the next two bytes starting at $6E, the vRefNum of the last volume used to store a PostScript file. It also uses the directory ID field at offset $70 to indicate the last directory used for storing a PostScript file. This is only so the Standard File dialog put up by PrJobDialog can start with the most appropriate directory; it’s not important to programmatic control of this mechanism.
Figure 2 shows the LaserWriter driver’s version of the print record, redeclared with the newly-documented information as lwTHPrint:
TYPE
{ Print Job: Print "form" for a single print request. }
When you print in the foreground, the LaserWriter driver uses the information in the print record to create the PostScript file. When you print in the background, the LaserWriter driver adds a resource with the information to the spool file so PrintMonitor can do the same thing. This lets this method work in both the foreground and background cases.
Be careful about picking file names to use—whatever method you use, if the file name is not unique, the LaserWriter driver will attempt to delete the existing file and cause you, as Hugo puts it, “endless grief.” Simply examining the directory at spooling time isn’t enough if there’s any chance the file name might not be unique when PrintMonitor gets around to despooling the file. Furthermore, if you try to write over an existing file, the LaserWriter driver will not change the end-of-file position, so the result file will have the larger EOF of the new file and the old contents. This is also Bad.
Here’s a summary of what we’ve discussed:
1. Get a print record ready to start your printing loop.
2. Change the fPSFile bit to tell the LaserWriter driver to create a PostScript file instead.
3. Set the vRefNum and directory ID for where you want to store the file.
4. Allocate a 64-byte pointer to store the file name; put the filename in the new memory block and put the pointer in the print record.
5. Complete your print loop as normal.
6. Zero the file name pointer in the print record as a precaution.
7. Save or otherwise manipulate the print record for future use.
Samples? Sure.
The following System 7-only sample routine PrPSFileDialog can be used in place of PrJobDialog when using this technique. Note that the routine requires a handle of type lwTHPrint.
Note: Be careful about bypassing the job dialog. The LaserWriter driver resets some other job-specific parameters (besides the file to save PostScript in) in PrJobMain. If you save a print record immediately after calling PrJobDialog and use that print record without going through the job dialog again, all of the job-specific parameters will be preserved (number of copies, page range, feeder choice, etc.). This may not be what you intended.
FUNCTION PrPSFileDialog(thePrRecHdl: lwTHPrint): BOOLEAN;
VAR
ourReply: StandardFileReply;
tempFlags: INTEGER;
tempResult: BOOLEAN;
ourOSError: OSErr;
tempPtr: Ptr;
BEGIN
PrPSFileDialog := FALSE; { being conservative }
tempResult := PrValidate(THPrint(thePrRecHdl));
IF NOT thePrRecHdl^^.prFlag1.fPSFile THEN
{ don't do this if there's already a file to be saved! }
thePrRecHdl^^.lastDirID := ourReply.sfFile.parID; {ID of
user-chosen directory}
PrPSFileDialog := TRUE;
END {IF good THEN…}
END {if flag was clear}
END;
PR 12 - SetLineWidth Revealed
Printing
Revised by: March 1988
Written by: Scott "ZZ" Zimmerman November 1987
This technical note describes the internal implementation, and correct method of using, the SetLineWidth Picture Comment.
The SetLineWidth picture comment provides a way of accessing PostScript’s 'setlinewidth' operator. Since the LaserWriter resolution is roughly four times that of the Macintosh screen, fractional line widths can be printed. The SetLineWidth PicComment provides a way for applications to access these fractional line widths through PostScript, without having to use floating point numbers.
First of all, the LaserWriter has an internal state that is stored in a number of PostScript variables. For more information on PostScript variables, see the PostScript Language Reference Manual. Some operations performed on the LaserWriter cause the values of these variables to change. One of these variables contains the width of the printer’s pen. The SetLineWidth picture comment works by changing the value of this variable.
Before we look at what the SetLineWidth comment does, let’s look at the argument passed to the comment. The argument is represented as a QuickDraw Point, however it is interpreted by the LaserWriter as a fraction. The LaserWriter interprets a point(h,v) to be a real number whose value is (v / h). This means that a point whose value is h=2, v=1, will be converted to 0.5 before being used by the LaserWriter. If you wanted to pass a value of 0.25, you would pass a point whose value is h=4, v=1. For 1.25, pass a point, h=4, v= 5.
In addition to the pen width variable, there is a variable that is used for scaling the pen’s width. This variable, named pnm for PeN Multiplier, contains a real number which is applied to the pen width. The default value of pnm is 1.0, which causes no scaling of the line width.
Whenever the SetLineWidth PicComment is sent to the LaserWriter, the current value of pnm is replaced by the value passed to the PicComment. The current pen size is then scaled by the new value of pnm. The following example will display four lines of different sizes. It is meant to illustrate the interaction between the QuickDraw PenSize procedure and the SetLineWidth PicComment.
TYPE
widthHdl = ^widthPtr;
widthPtr = ^widthPt;
widthPt = Point;
VAR
theWidth: widthHdl;
BEGIN
(* Initialize the print manager as per Inside Macintosh II-155. *)
At this point, it is assumed that PrPageOpen has been called, and the print manager is ready to accept data.
The first thing we do is set the scaling factor to 1.0. This way, no scaling will be performed when we call PenSize.
DrawString('5.0 times 1 point pen size = 5 point thickness.');
If any calls to PenSize are made at this point, the new pen size will be scaled by 5.0. This is because the SetLineWidth PicComment is still in effect. We will now send a SetLineWidth PicComment to revert the scaling factor back to 1.0.
DrawString('0.2 times 5 point pen size = 1 point thickness.');
Since the scaling is once again 1.0, PenSize calls at this point will not be scaled. Here we explicitly set the scaling factor to 1.0 before changing the pen size. This makes it easier to see what scaling will be applied to the next call to PenSize.
DrawString('1.0 times 1 point pen size = 1 point thickness');
(* Dispose of the handle when you are through with it! *)
DisposHandle(Handle(theWidth));
When printed, the above example will produce the following:
To summarize, there are four things to remember when using the SetLineWidth PicComment:
1. The argument to the SetLineWidth PicComment is specified as a point, though it is actually interpreted by the LaserWriter as a real number. The point value is specified as h,v, and the LaserWriter interprets the value as v / h.
2. The SetLineWidth PicComment affects both the height and width of the pen, even though the name suggests otherwise.
3. When you send the SetLineWidth PicComment, the current pen size will be scaled. Any drawing that is done after the PicComment is set, will be done with the scaled pen size.
4. When you call the QuickDraw PenSize procedure, the pen size will be scaled after it has been set. For example, if your scaling factor is 0.5, and you set the pen size to 2,2, the actual pen size will be 1,1. If you don’t want the scaling to occur, make sure to send a SetLineWidth PicComment, with the point argument set to 1,1. The next call to PenSize will then be scaled by 1.0, which will have no effect.
Further Reference:
• LaserWriter Reference Manual
• PostScript Language Reference Manual
• PostScript Language Tutorial and Cookbook
PR 13 - Spooler Queries?
Printing
Revised by: March 1988
Written by: Ginger Jernigan July 1987
When the LaserShare spooler is on an AppleTalk network, it acts like a LaserWriter-type device, which can be chosen and communicated with much like a real LaserWriter. Some applications, however, must communicate with a LaserWriter directly, not a spooler. If this is true for your application, you can check whether you are actually talking to a real LaserWriter by sending to the LaserWriter the following query:
%!PS-Adobe-1.2 Query
%%Title: Query to Spooler/Non-Spooler status
%%?BeginSpoolerQuery
(0) = flush
%%?EndSpoolerQuery 1
%%EOF
(The query has to be sent using the Printer Access Protocol (PAP). The object code for PAP is available from Licensing.) If the string returned begins with a ‘%%’ then it is a status string and you can ignore it and wait for another string. If the LaserWriter is actually a LaserShare spooler, then the string that is returned will be ‘1’. If the LaserWriter is a real LaserWriter then the string returned will be ‘0’.
Further Reference:
• PostScript Language Reference Manual
• Adobe Systems Document Structuring Conventions
PR 14 - Dictionary Downloading
Printing
Written by: Zz Zimmerman April 1991
This technical note discusses a method for downloading PostScript dictionaries automatically using the LaserWriter driver. It will also provide the format and use of the PREC(103) resource. It will also describe some problems with the now obsolete PREC(201) resource. If you are using PostScript dictionaries, or either of these resources, you should definitely read this note.
Introduction
Although many picture comments have been added to support the features of PostScript that are missing from Quickdraw, many developers have still taken to sending PostScript directly from their applications. As the use and complexity of this PostScript code increases, more and more developers are finding it necessary to define and use their own PostScript dictionaries. PostScript dictionaries are basically collections of variables and procedures that can be predefined, and accessed later. They are used to prevent conflicts between the symbols used by applications and those used by system software (such as the LaserWriter driver's LaserPrep dictionary). Unfortunately, because of the LaserWriter drivers habit of using the PostScript 'save' and 'restore' operators, there are problems with keeping a PostScript dictionary defined. PostScript definitions made by code sent with the print job (ie. sent between the calls to PrOpenPage/PrClosePage) will be lost the first time the LaserWriter driver calls 'restore'. There are a couple of solutions to this problem, but one that hasn't been documented before involves the use of the PREC(103) resource. If the LaserWriter driver finds a resource of type PREC with an ID of 103, it will download the PostScript code to the LaserWriter before performing the initial 'save' operation. This means that any definitions made by the PostScript code stored in the PREC(103) resource will remain defined for the duration of the print job, independent of the LaserWriter driver's calls to save and restore.
Caveats
The PREC(103) method is a great way to get a dictionary downloaded at print time. Unfortunately, this does not solve the problem for using dictionaries in export files like PICT. If you insert PostScript code into Quickdraw pictures, the system is not smart enough to record the PREC(103) code into the picture. Instead, you must record the dictionary using the standard PostScript picture comments (defined in Technical Note #91, Optimizing for the LaserWriter–PicComments). You should also use the appropriate PostScript structuring comments as defined by the Adobe Document Structuring Conventions. If you use the Adobe comments correctly, an application that is importing your picture will have the option of parsing for the procedure set comments, and extracting the dictionary definition to be placed in a PREC(103) resource at print time.
The next caveat concerns the use of multiple PREC(103) resources. At PrOpenDoc time, the LaserWriter driver makes one GetResource call to load the resource of type PREC with an ID of 103. Because the call is a GetResource call (instead of Get1Resource), the PREC can be stored in any open resource file. To avoid any conflicts, the resource should be stored in the resource fork of your application, or in the document file that is referencing the PostScript dictionary. Because the GetResource call is only made once, only the first PREC resource found by GetResource will be used. Any other PREC(103) resources will be ignored. As long is this resource is only used by applications, there is no problem since there can only be one application active at any particular time. If the resource is used by other elements of the system (ie. desk accessories, drivers, INITs), you can easily run into the problem of your PREC resource being ignored. The best solution to this problem is to only use the resource from within an application.
Since the PREC(103) resource is considered part of the print job, the definitions it makes are lost when the job ends (ie. when the LaserWriter receives EndOfFile from the Macintosh). Because of this, the code you place in the PREC(103) resource should not attempt changing any persistent parameters in the printer. The means avoiding the PostScript 'exitserver' operator. You should also avoid calling other routines that reset the current state of the printer (ie. initclip, initgraphics, etc.). Use of these operators will have a serious effect on Quickdraw operations that may be present in the print job.
When the PREC(103) resource was originally introduced, it had a cousin called PREC(201). PREC(201) was similar to the PREC(103) resource in that it allowed PostScript to be downloaded to the printer before the actual print job. The difference between the two resources was that the PREC(201) resource downloaded the PostScript code at the same time that it downloaded the LaserPrep dictionary, outside of the PostScript 'server loop'. Because of this, any definitions made by the code in the PREC(201) resource would remain after the current job. Like the LaserPrep dictionary, the dictionary downloaded in PREC(201) would remain until the LaserWriter was rebooted (ie. powered off then on again). Although this feature was useful in some situations, it did have its problems. Not the least of which was the valuable printer memory consumed by the dictionary that was downloaded. Since the dictionary remained after the job that required it, subsequent jobs had less memory available to them. The only way to reclaim the memory was to reboot the printer, and this was not obvious to naive users. The other problem was introduced when background printing became available. With background printing enabled, the LaserWriter driver could no longer count on the PREC(201) resource always being available. Since you could no longer store the resource in the LaserWriter driver (because of the LaserWriter driver being MultiFinder compatible - see Learning To Drive for more information), it has to be stored in a separate resource file. This made it virtually impossible for the LaserWriter driver to find the resource when it was required. For this reason, the PREC(201) resource is only downloaded when background printing is turned off.
Needless to say, we don't recommend the use of features that only work in certain situations, so the PREC(201) resource is now considered unsupported and obsolete. If you are using the PREC(201) resource, you should be able to revise your application to use the PREC(103) resource instead, with only a small performance penalty. On the bright side, the PREC(201) resource will continue to be supported in the foreground through the 7.0 version of the LaserWriter driver, and most likely, until the new printing architecture becomes available, giving you plenty of time to revise...
Implementation
The PREC(103) resource can be implemented by simply creating the resource with ResEdit or Rez, and then storing it in an open resource file at print time. In the case of ResEdit, you should create a new resource of type PREC with an ID of 103. You should then open the new resource using the resource template for string ('STR ') resources. You can then type your PostScript code directly into the resource.
If you would rather keep your PREC definition as a Rez source file with the rest of your project, you can do this by simply defining the PREC resource type at the top of the file, followed by an instance of the PREC resource. Consider the following Rez source code:
/* First the resource type definition: */
type 'PREC' {
string;
};
/* Now the real resource definition: */
resource 'PREC' (103) {
"userdict /mydict 50 dict def";
};
We begin by defining the resource type as being a string. We then define an instance of the resource with an ID of 103. Finally, we define the contents of the resource. The PostScript code above basically defines a dictionary named mydict within the userdict dictionary. The mydict dictionary is defined as having a maximum of 50 elements. Consult the PostScript Language Reference Manual for more information concerning legal operations on dictionaries.
Conclusion
The PREC(103) is a simple, efficient way to download a PostScript dictionary at print time. It does not solve the problem of exporting PostScript that references a dictionary into file formats such as PICT, but it can help. Applications can be revised to extract PostScript dictionary definitions from files such as PICT and download them at print time using the PREC(103). It should be noted however that this is not automatic, the application must parse the picture to get this functionality. Finally, the PREC(201) resource can only be supported when background printing is disabled, so it is now considered obsolete, and use of it is unsupported.
Further Reference:
• PostScript Language Reference Manual, Adobe Systems Inc.
• Adobe Document Structuring Conventions, Adobe Systems Inc.
• LaserWriter Reference Manual, Addison-Wesley
PostScript is a registered trademark of Adobe Systems Incorporated.
PR 15 - Feeder Fodder
Printing
Written by: Zz Zimmerman April 1991
This Technical Note discusses the new Feeder button available in the 6.1, and 7.0 versions of the LaserWriter driver. This Feeder button mechanism allows developers to insert code into the LaserWriter driver to support a sheet feeder connected to a LaserWriter. This Note provides a description of the button, as well as information required to implement one.
Introduction
The LaserWriter driver now implements a standard method for handling sheet feeders. Most LaserWriter sheet feeders need a way to present a user with a dialog as well as a way to download the PostScript® code necessary to control the feeder. In the past, most manufacturers resorted to modifying the LaserWriter driver’s code resources; however, this functionality is now possible without the need to patch existing resources in the driver—by adding three new resources.
When the LaserWriter driver notices these three special resources in its resource fork, it displays a Feeder button in the lower right corner of the Print dialog box. It is important to note that this feature is not provided for general application use, but rather only for developers of sheet feeders and other LaserWriter add-on devices. The button is always labeled Feeder, and there can be only one set of Feeder resources in the LaserWriter driver. Because of this restriction, you should not attempt to use this feature to implement anything other than a sheet feeder.
The first special resource contains code to implement the user interface of the feeder, and the other two contain the PostScript code required to drive the feeder. When an application calls the LaserWriter driver to display the Print dialog box, the driver looks for three resources of type 'feed' and displays the Feeder button in the lower right corner of the dialog box if they are found. If no 'feed' resources are available, it does not display the Feeder button.
When a user selects Print, the driver displays the standard Print dialog box with the Feeder button. If a user clicks on the Feeder button, the driver displays a dialog box in front of the Print dialog box, which allows the user to configure the feeder, then returns to the Print dialog box once the user confirms or cancels the feeder configuration. This feeder dialog box should not contain an option to print, as this could override choices made in the standard Print dialog box.
Implementation
To handle interaction with the user, you must install a resource of type 'feed' (ID = -8192) into the LaserWriter driver with the code required to manage the dialog box. Like all Printing Manager code resources, this resource begins with a jump table, followed by the actual code. The code is implemented as a procedure that is passed a single parameter. This parameter is a rectangle defining the page size selected by the user. This page size is equivalent to the rPaper rectangle in the print record, meaning it defines the actual page size, not just the printable area. The rectangle is expressed in 72 dpi coordinates and has a negative origin.
Go Ahead and Jump
The jump table consists of a 68000 JMP instruction that jumps to the proper offset in the resource. In this case, there is only one routine, so the code starts immediately following the jump table. To make this step automatic, the jump table is created using a small assembly language header:
IMPORT Feeder ; Feeder is NOT defined here...
Start MAIN EXPORT ; This is the main entry point for the linker.
JMP Feeder ; The one jump table entry in this table.
END
This example first imports the Feeder procedure, which can be defined externally in the language of your choice. Next is Start, the main entry point to the jump table. By passing this label to the link command, the jump table is located at the beginning of the resource. The next line is the actual jump table entry, and the END is required to end the assembly-language header. That’s all there is to it. The only thing one should have to change in this code fragment would be the name of the routine to import.
The Real MacCode
Now that the jump table is complete, it needs some place to jump. Although MPW C and Pascal examples are provided in this Note, the code can be written in any language. As mentioned before, the code is implemented as a procedure that takes one parameter.
C Definition
In C, this looks like:
#include <Types.h>
#include <Quickdraw.h>
void FEEDER(Rect *r)
{
<Code to present and handle dialog...>
}
Since the assembler converts all labels to uppercase, the name of the procedure FEEDER must be capitalized to match the case of the label in the jump table. If you are using MPW, you can use the assembler's CASE directive to prevent the assembler from capitalizing the labels. Since the rectangle is passed using the C calling convention (i.e., the caller strips the parameter), there is no need to declare the procedure as type Pascal. However, this convention does make things a little more interesting for the Pascal version:
Pascal Definition
If you are using MPW, you can use the Pascal compiler's C directive to define the Feeder procedure as using the C calling convention. This makes the definition look like this:
UNIT FeederSample;
INTERFACE
USES Types, Quickdraw;
PROCEDURE Feeder(r: Rect); C;
IMPLEMENTATION
PROCEDURE Feeder(r: Rect);
BEGIN
<Code to present and handle dialog...>
END;
END.
So this is straight forward. The procedure Feeder is defined as having one parameter (r), and the C directive is used so that the stack is handled correctly.
If you are using some other development environment that doesn't support the C directive, you have to do a little more work, making the definition look like this:
UNIT FeederSample;
INTERFACE
USES Types, Quickdraw;
PROCEDURE Feeder;
IMPLEMENTATION
FUNCTION StealRectalParam: Rect;
INLINE $2EAE, 0008; { MOVE.L 8(A6),(A7) }
PROCEDURE Feeder;
VAR
r: Rect;
BEGIN
r := StealRectalParam;
<Code to present and handle dialog...>
END;
END.
First of all, a unit is defined, and the proper interfaces are included. The definition of the Feeder procedure in the INTERFACE section is required to make the label available to external modules. In the IMPLEMENTATION section, one starts with the StealRectalParam function, which is used to get the rectangle passed by the Printing Manager without actually removing it from the stack. If you declared the rectangle as a parameter to the Feeder procedure, Feeder would remove the parameter before returning, then when the caller tried to remove the parameter again, the stack would be invalid and would cause a crash.
To solve this problem, define the Feeder procedure with no parameters. This way, the Feeder procedure leaves the parameter right where the caller left it. To get the parameter without removing it from the stack, use the StealRectalParam function, which moves the parameter from its normal location (off of A6) into the location pointed to by the stack pointer. Since StealRectalParam is a function, the stack pointer is already pointing to the return value. When StealRectalParam returns, the Feeder routine gets the rectangle parameter, without having removed it from the stack.
Tickled Link
Now you have the jump table and the code, but you still need to link them together. This step is pretty simple, but remember to specify the starting location of the jump table. It looks like the following:
First tell the linker to link the code into a 'feed' resource with an ID of -8192. Next, specify that the resource begins with the code at label START. This label was defined by the assembly-language used to generate the jump table. Finally, tell the linker to link all of the code into a single segment named Feeder. Obviously, the list of libraries and object files changes depending upon the language used, but the directives to the Link command should remain the same.
Well Fed
So that should be enough to get some code into the 'feed' resource. Now you need to actually control the feeder during the print job. To do this, you must use PostScript. Your driver should also provide a 'feed' resource of -8191 containing PostScript code. This code is downloaded by the LaserWriter driver prior to downloading the rest of the job. For those familiar with the 'PREC' 103 resource, the PostScript in the 'feed' resource is downloaded before the 'PREC' 103 code. Additional PostScript to be downloaded can be stored in 'feed' -8190. The PostScript code in the 'feed' resource should redefine (i.e., patch) the PostScript operators required to handle switching feeders. A likely candidate is the showpage operator called at the end of each page. As always, calling or redefining operators defined by the LaserPrep (md) dictionary is not supported. If your device is connected via the LaserWriter’s serial port, you can license code from Adobe Systems, Inc. that makes it possible to access the serial port while the LaserWriter is connected over AppleTalk. For more information, contact Adobe at:
Adobe Systems, Inc.
1585 Charleston Road
Mountain View, CA 94043
(415) 961-4400
Once a user has confirmed the configuration from the dialog box, you can edit the PostScript code in the -8191 resource to reflect the choices made. However, when MultiFinder is active, you cannot add or change the size of resources in the LaserWriter driver. For this reason, you should pad the 'feed' -8191 resource to the maximum size. This padding can be done by adding spaces at the end. If you later need to resize the resource, you can simply overwrite some of the spaces. For more information on printer drivers under MultiFinder, see the Learning to Drive document, which is part of “Developer Essentials,” and is available on AppleLink, the Apple FTP site, and the Developer CD Series.
You probably need to provide other resources along with the 'feed' resources; for example, you need 'DITL' and 'DLOG' resources for the dialog box. This is okay, but you should be sure to pick unique resource types to avoid confusing the LaserWriter driver. In the case of a Feeder button, you are a guest in someone else’s house. It would be wise to avoid rearranging the furniture.
When the LaserWriter driver actually opens the connection to the printer, it looks for 'feed' resources -8191 and -8190. If they exist, they are downloaded. For those familiar with the 'PREC' 103 method of downloading PostScript code (refer to Technical Note #192, Surprised in LaserWriter 5.2 and Newer), the 'feed' resources are downloaded before the 'PREC' 103 resource. In the case of background printing, the resources are copied into the spool file. Since 'feed' resources -8191 and -8190 are automatically downloaded by the LaserWriter, they must contain PostScript code. The format of these PostScript resources is a string of ASCII characters without any length byte or terminator. The size of the string is determined by the size of the resource; there are no special size restrictions on these resources, and their only requirement is that they contain PostScript code. To make debugging easier, you should separate lines of PostScript using a carriage return character (13 or $0D hex).
Don't Feed The Print Monster
One last important note concerns the 6.1 version of the LaserWriter driver, shipped on the Macintosh Printing Tools disk included with the Personal LaserWriter LS and StyleWriter. In this version of the driver, the Feeder button will only work when Background printing is disabled. There is a problem with the driver finding the 'feed' resources when Background printing is enabled. This problem has been solved in the 7.0 version of the driver which should be used instead of the 6.1 driver as soon as it is available. Since there is no workaround for the problem, you don't really have to do anything except for possibly noting it in your documentation. Any note should recommend upgrading to the 7.0 version of the driver as soon as possible.
Driving Miss Lasey
Now that you have the two or three 'feed' resources, the big question is installation. How should you ship these things? There are two methods. The first method involves licensing the LaserWriter driver from Apple Software Licensing (SW.License on AppleLink). This method is only required for “turn-key” systems, where all installation is done for the user and you must ship the LaserWriter driver as part of your product. The second method, which is by and large preferred as it requires no licensing, is to ship your resources in an installer application. This application simply opens the LaserWriter file and adds the necessary resources.
Conclusion
So this should be all the information you need to implement the feed resources for your device. If you intend to drive a sheet feeder through the LaserWriter’s serial port, be sure to contact Adobe Systems, Inc. for the most current implementation and licensing information. Although the Feeder button could theoretically be used for other purposes, it will always be labeled “Feeder” by the LaserWriter driver. Because of this consistency, developers should not attempt to extend its functionality beyond support for sheet feeders.
Further Reference:
• PostScript Language Reference Manual, Adobe Systems Inc.
• Technical Note M.IM.LWDriverSuprises —
Surprises in LaserWriter 5.2 and Newer
PostScript is a registered trademark of Adobe Systems Incorporated.
PR 16 - Fun With PrJobMerge
Printing
Revised by: Matt Deatherage May 1992
Written by: Scott “Zz” Zimmerman and Matt Deatherage March 1992
This Technical Note discusses some interesting behavior you’ll encounter while using PrJobMerge with the 7.0 and 7.1 versions of the LaserWriter driver.
Changes since March 1992: Corrected the Vulcan-like “THPring” typo to correctly read “THPrint,” and changed a comment in the code to mean what I originally meant.
Like many Printing Manager calls, PrJobMerge is implemented by the currently chosen printer driver. This makes sense after consideration—since the printer driver may store job-specific information anywhere in the print record, only the printer driver can correctly merge this into a destination print record.
The LaserWriter driver’s implementation of PrJobMerge has a few bugs in versions 7.0 and 7.1.
Fun Thing #1
Historically, PrJobMerge hasn’t worked correctly in the LaserWriter driver. The driver does not correctly merge all job-related data (like the number of copies requested) into the destination print record, so printing multiple copies of multiple documents from the Finder isn’t really possible with the LaserWriter driver.
The only possible workaround is to present a different job dialog for each document to be printed, but this isn’t recommended—especially since the job dialog doesn’t tell you which document you’re about to print.
Fun Thing #2
As if this wasn’t enough excitement for one driver, in versions 7.0 and 7.1 of the LaserWriter driver PrJobMerge actually manages to destroy all the job-specific information in the source print record after it doesn’t copy it into the destination print record.
There is a workaround for this problem—make a copy of the source print record and pass the copy to PrJobMerge. If you pass the copy to PrJobMerge, you can just replace PrJobMerge with your own routine that makes a copy, merges it into the destination, and disposes of the copy. This will work for all printer drivers, although it’s necessary only with version 7.0 of the LaserWriter driver.
hPrintTemp := hPrintSrc; {make our own copy of the print record handle}
copyError := HandToHand(Handle(hPrintTemp));
PrSetError(copyError); {so we can get it later}
IF copyError = noErr THEN BEGIN
{hPrintTemp is now a copy of the original source record}
PrJobMerge(hPrintTemp,hPrintDst); {This messes up hPrintTemp, but we
don't care}
END; {if copyError = noErr}
IF hPrintTemp <> NIL THEN DisposHandle(Handle(hPrintTemp)); {only a copy,
remember!}
END;
Don’t Go Overboard Trying to Solve This
Although the bugs in PrJobMerge in versions 7.0 and 7.1 of the LaserWriter driver make certain kinds of printing multiple documents impossible without device-specific workarounds, we strongly encourage you not to implement such code. Any code that tries to replicate the function of PrJobMerge must by nature depend on how the LaserWriter driver stores information in the print record, and this is a Bad Thing. The road to Compatibility Hell is paved with good intentions.
If you write your code as described in this Note, it will behave properly when the bug is fixed without change on your part. If you go overboard trying to write your own PrJobMerge function, your application is a prime candidate for compatibility problems.
Further Reference:
• Inside Macintosh, Volume II, The Printing Manager
PR 17 - ImageWriter II Paper Motion
Printing
Revised by: March 1988
Written by: Ginger Jernigan April 1986
The purpose of this technical note is to answer the many questions asked about why the paper moves the way it does on the ImageWriter II.
Many people have asked why the paper is rolled backward at the beginning of a Macintosh print job on the ImageWriter II. First, note that this only happens with pin-feed paper (i.e. not with hand-feed or the sheet-feeder) and only at the beginning of a job.
It is not a bug, and it is not malicious programming. It is simply that users are told in the manual to load pin-feed paper with the top edge at the pinch-rollers, making it easy to rip off the printed page(s) without wrecking the paper that is still in the printer or having to roll the paper up and down manually. At the end of every job, the software makes sure that the paper is left in this position, leaving the print-head roughly an inch from the edge. If something is to be printed higher than that, the paper has to be rolled backwards.
As you are probably aware, the “printable rectangle” (rPage) reported to the application by the print code begins 1/2 inch from the top edge, not one inch. The reason for that is that we want a document to print exactly the same way whether you are printing on the ImageWriter I or II. On the ImageWriter I, the paper starts with the print-head 1/2 inch from the top edge, so the top of rPage is at that position for both printers.
There is no way to eliminate the reverse-feed action, because the user would have to load the paper a different way AND the software would have to know that this was done.
Incidentally, in addition to the paper motion described above, there is also the “burp.” This is a 1/8-inch motion back and forth to take up the slop in the printer’s gear-train. It is needed on the old-model printer, and there is debate about whether or not it’s needed on ALL ImageWriter IIs, or only some, or none. The burp has been in and out of the ImageWriter II code in various releases; right now it’s in.
PR 18 - The Effect of Spool-a-page/Print-a-page on Shared Printers
Printing
Revised by: March 1988
Written by: Ginger Jenigan May 1987
This technical note discusses drawbacks of using the spool-a-page/ print-a-page method of printing.
The “spool-a-page/print-a-page” method of printing prints each page of a document as a separate job instead of calling PrPicFile to print the entire picture file. Many applications adopted this method of printing to avoid running out of disk space while the ImageWriter driver was spooling the document to disk. As long as you are printing to a directly connected ImageWriter, you’re fine, but if you are printing to remote or shared devices (like the AppleTalk ImageWriter and the LaserWriter), this method may create significant problems for the user.
When a job is initiated by the application, the driver establishes a connection with the printer via AppleTalk. When the job is completed, the driver closes the connection, allowing another job the opportunity to print. If each page is a job in itself, then the connection is closed and reopened between each page, allowing another application to print between the pages of the document, which, as you might imagine, could present a significant problem. If two people are printing to the same AppleTalk ImageWriter at the same time and their applications use the “spool-a-page/print-a-page” method of printing, the pages of each document will be interleaved at the printer.
Although there are good reasons for using this method of printing, it is only useful for a directly connected printer. From a compatibility point of view, this method of printing is built-in device dependence. Also, this method could create serious problems for other types of remote devices. Therefore, we are recommending that applications avoid using this method indiscriminately. You should check available disk space to see how much room you have before you print. If there isn’t enough space for your entire document, then print as much as you can (to minimize the interleaving) before starting another job. Whenever possible, applications should use the print loop described on page II-155 in The Printing Manager chapter of Inside Macintosh.
Further Reference:
• Printing Manager
• Technical Note M.IM.LaserWriterOpt —
Optimizing for the LaserWriter—Techniques
PR 19 - Using Laser Prep Routines
Printing
Revised by: March 1988
Written by: Ginger Jernigan July 1987
This technical note addresses the issues involved in depending on the procedures and constants defined in the Laser Prep dictionary.
When you are writing an application that uses PostScript heavily, it is very tempting to call the procedures already defined in the Laser Prep dictionary, rather than taking up the space in the printer’s memory with PostScript procedures of your own. Or, if a procedure in the dictionary doesn’t do what you need it to do, it is tempting to go in and change it to do what you really want.
Unfortunately, we cannot guarantee that either the name or the function of a particular procedure in the dictionary will stay the same when the LaserWriter driver changes. In addition, some procedures may become obsolete and go away when the driver changes. Since the Laser Prep dictionary is considered part of the source for the LaserWriter driver, Apple reserves the right to make any changes to it that are deemed necessary.
Because we cannot guarantee the permanence of the contents of the Laser Prep dictionary, relying on its contents can pose a significant compatibility problem. If you rely on the procedures defined in the Laser Prep dictionary, your application will have to be revised every time Apple releases a new LaserWriter driver.
If you feel that you absolutely must use or modify procedures in the Laser Prep dictionary, you must always check the version that is loaded into the printer before you print. This allows your application to take appropriate action if the version of the dictionary that has been downloaded to the printer isn’t one that you know about.
How To Check The Laser Prep Dictionary Version
To determine the version of Laser Prep that the printer may contain, you have to communicate with the printer using the Printer Access Protocol (PAP); you can’t just send your query through the LaserWriter driver because there is no way to get an answer back. The object code and documentation for PAP are available from Apple’s Licensing department.
To determine whether the dictionary has been downloaded and whether it is the right one, send the following PostScript code to the printer:
%!PS-Adobe-1.2 Query
%%Title: Query to establish Laser Prep ProcSet version propriety
%%?BeginProcSetQuery: AppleDict md xx
/md where{
/md get /av get cvi xx eq
{(1)}{(2)}ifelse}
{(0)}ifelse = flush
%%?EndProcSetQuery: unknown
%%EOF
md is the name of the Apple dictionary and xx is the version number you want.
Note: /av is a constant in the md dictionary which contains the dictionary’s version number. This is the only object in the dictionary whose name and function are guaranteed not to change.
From the printer you will receive a string. If the string returned begins with ‘%%’, it is a Status response. You can ignore it and wait for another string.
If the response is ‘0’, the dictionary hasn’t been downloaded yet; you will need to determine how to best handle this situation for your application.
If the response is ‘1’, the printer is loaded with the correct version of the dictionary.
If the response is ‘2’, then the dictionary exists but it isn’t the version you need. In this case you need to either let the user know, or proceed in as standard a fashion as possible, without calling or modifying routines contained in the Laser Prep dictionary.
Translating PostScript Files
Some applications interpret the PostScript files that are generated by the LaserWriter driver when the user presses command-F (generates document only) or command-K (generates dictionary and document) after clicking on the OK button in the Job dialog. A typical application might translate these PostScript files into another page description language.
This kind of application requires intimate knowledge of the contents of the dictionary in order to be able to do the translation, because it may have to expand the procedures used to their actual values before it can then translate the PostScript to another language. This poses a significant compatibility problem. Since we cannot guarantee that the contents of the dictionary will not change, these types of applications will have to be revised every time we release a new version of the LaserWriter driver. Also, there is no way to know which version of the LaserWriter driver generated the PostScript file the application is interpreting. You will have to require that a particular version of the LaserWriter driver be used to generate the PostScript files that your application will interpret.
Printer Independence
Applications that are written to take advantage of the routines in the Laser Prep dictionary are, of course, highly device dependent. Being device dependent can drastically reduce your chances of being compatible with future printer-type devices. For a more detailed discussion of this issue, please refer to Technical Note #122.
Further Reference:
• The Printing Manager
• PostScript Language Reference Manual
• Technical Note M.IM.DevIndPrinting —
Device-Independent Printing
PR 20 - LaserWriter Driver Surprises in 5.0 and Newer
Printing
Revised by: Mary Burke & Scott “Zz” Zimmerman February 1990
Written by: Scott “Zz” Zimmerman April 1988
This Technical Note describes some changes in version 5.0 and later LaserWriter drivers.
Changes since April 1988: Described a bug in 5.x which is fixed in 6.0 and later, and reiterated a warning about storing fonts in an application.
With the release of LaserWriter 5.0 and background printing, a few changes had to be made to the LaserWriter driver. Although these changes were transparent to most applications, some have had problems. Most of these problems are related to use of unsupported features. This Note details a partial list of the changes.
No Mo’ Low
Because of the problems supporting both the high-level and low-level interfaces in the background, the low-level interface is all but removed. Instead of the low-level calls being executed by the device driver, the _PrCtlCall procedure converts the call into its high-level equivalent before execution. This way, the LaserWriter driver has a common entry point for both the low-level and high-level interfaces. Because of this conversion, the low-level calls may not be faster than using the high-level equivalents. In some cases, they may even be slower.
Version 5.x of the LaserWriter driver also contains a bug with the low-level interface. If an application which uses the low-level Printing Manager interface encounters an error during the course of the print job, the LaserWriter driver crashes before the application has a chance to see the error. Because the error occurs inside the driver, there is no way for an application to predict or work around this problem. The only solution to this problem is to use the high-level Printing Manager interface or to upgrade to version 6.0 or later of the LaserWriter driver which fixes this bug.
Are You Convertible?
Whereas the conversion of the low-level calls should be transparent, the conversion routines make some assumptions. The conversion routines require a context in which to operate; the Printing Manager maintains a certain state while executing commands, and the conversion routines need access to this state to perform the conversion. To provide this context, an application must have opened a document and a page. This requirement means that the original method of using the low-level interface, which is documented in Inside Macintosh, Volume II-164, no longer works, as in the following example:
PrDrvrOpen;
PrCtlCall(iPrDevCtl, lPrReset, 0, 0);
{ Send data to be printed. }
PrCtlCall(iPrDevCtl, lPrPageEnd, 0, 0);
PrDrvrClose;
Instead, an application should use the following:
PrDrvrOpen;
PrCtlCall(iPrDevCtl, lPrDocOpen, 0, 0);
PrCtlCall(iPrDevCtl, lPrPageOpen, 0, 0);
{ Send data to be printed. }
PrCtlCall(iPrDevCtl, lPrPageClose, 0, 0);
PrCtlCall(iPrDevCtl, lPrDocClose, 0, 0);
PrDrvrClose;
This method provides the Printing Manager with the context it needs to convert the calls.
Really Unsupported Features
Sending data to the printer between the _PrOpenDoc or lPrDocOpen and the _PrOpenPage or lPrPageOpen calls is not currently, and has never been supported. LaserWriter drivers prior to 5.0 interpreted this data, but 5.0 and later drivers ignore it. To download an application-specific PostScript® dictionary as a header with each document, Apple recommends that the application provide a 'PREC' resource of ID = 103, as is described in the LaserWriter Reference.
A Little Less Control
Four of the six printer control calls originally supported by the LaserWriter driver have been discontinued due to lack of use and difficulty supporting with background printing. The four calls which follow were only supported by the LaserWriter driver and only documented in the LaserWriter Reference Manual:
°•° fill °•° hexBuf °•° printR °•° printF
In addition to these calls, the stdBuf call is also affected. There are two versions of the stdBuf call depending upon the sign of the bytes parameter. If bytes is negative, the text passed to the stdBuf call is converted to PostScript text before being sent to the LaserWriter. This conversion means that special PostScript characters in the text are preceded by a PostScript escape character. In addition, characters with an ASCII value greater than 128 are converted to octal before being sent to the LaserWriter. This version of the call is no longer supported.
If the bytes parameter is positive, the text passed to the call is sent directly to the LaserWriter without conversion and interpreted as PostScript instructions. This version of the call is still supported, but there is one more problem. When an application first opens the low-level driver (via _PrDrvrOpen) with background printing enabled, no clip region is defined. If the application then begins sending PostScript to the driver via the stdBuf call, all of the output is clipped, and only a blank page is printed.
To prevent this problem, the application must force a clip region to be sent to the LaserWriter. The region is sent by the driver when it receives its first drawing command. Unfortunately, the driver does not consider the stdBuf call to be a drawing command. To force the clip region on the printer, the application can use the iPrBitsCtl call to print a small bitmap outside the printable area of the page. This call does not have any effect on the document, but it fires the bottleneck routine and causes a definition of the clip region. Since the clip region is reinitialized at each call to lPrPageOpen, the application should send the bitmap once at the start of each page. If any other printer control calls precede the stdBuf call, the application does not need to send the bitmap.
Background Preparations
The 'PREC' ID = 201 mechanism only works when background printing is disabled. This limitation is because of difficulties finding the resource under MultiFinder. Since the option only works in the foreground, and since there is no way for an application to know if background printing is enabled, an application should avoid using this feature.
Fonts In An Application?
There are two problems when printing application fonts with the LaserWriter driver. Application fonts are fonts that are stored in the resource fork of the application’s resource file rather than being stored in the System file. The first problem occurs when the application font has the same name as the application’s resource file. If this is the true, the LaserWriter driver incorrectly assumes that the application’s resource file is a font file, and closes it after using the font. To solve this problem, developers should make sure the name of the application font (i.e., the 'FOND' resource) is different from the name of the application’s resource file. Since the application can still be renamed by the user, developers should try to select a unique font name. If the font name does not appear in a font menu, developers can simply append the application’s creator string onto the desired font name (i.e., 'MyApplicationFont ZZAP').
The second problem with application fonts only occurs when background printing is enabled. When a print job is performed in the background, the LaserWriter driver writes all of the data to be printed into a file (called a spool file) for printing at a later time by Print Monitor. Since the LaserWriter driver has no way of knowing when the file will actually be printed, it cannot assume that the application will still be open when the job is printed. This is a problem if the application contains application fonts that Print Monitor needs at print time. To solve this problem, the LaserWriter driver must determine whether the fonts needed by the application are resident in the System file or in the application file. If they are in the application file, the driver must copy them into the spool file so they are available to Print Monitor. This practice can lead to very large spool files, as well as a significant loss of performance when background printing is enabled. To solve these and other user interface problems related to application fonts, Apple strongly recommends that developers ship custom application fonts as suitcase files for the user to install in the System file.
Headin’ For Trouble
There is a minor bug in version 5.0 of the LaserWriter driver that only affects applications that parse the PostScript header downloaded by the driver with each document. This header contains some PostScript comments that provide information about the current job. One of these comments is IncludeProcSet. This comment takes three arguments: a PostScript dictionary name, a major version number, and a minor version number. In version 4.0 of the LaserWriter driver, the comment line looked like the following:
%% IncludeProcSet: (Appledict md) 65 0
Unfortunately, in version 5.0 of the LaserWriter driver, the last argument was removed. This caused the comment line to look like the following:
%% IncludeProcSet (Appledict md) 66
Since Adobe defined the comment to take three arguments, it is reasonable for applications that parse the comments to expect three arguments; therefore, version 5.1 and later of the LaserWriter driver contain the correct version of the comment:
%% IncludeProcSet (Appledict md) 67 0
No Go With Zero
Some applications want to force a font to be downloaded to the LaserWriter without actually printing characters with the font. This can be done in three easy steps:
1. Save the current pen position.
2. Use any text drawing routine to draw a space character.
3. Move the pen back to the saved position.
Some applications use _DrawString with a empty string (e.g., DrawString('')) to force the font downloading. Although this worked in LaserWriter drivers up to 5.0, these calls are ignored by the 5.1 and later drivers. The main reasons for this change were optimization of performance and a reduction in the size of spool files.
Further Reference:
• Inside Macintosh, Volumes II & V, The Printing Manager
• LaserWriter Reference Manual
PostScript is a registered trademark of Adobe Systems Incorporated.
PR 21 - Pictures and the Printing Manager
Printing
Written by: Zz Zimmerman April 1991
This technical note described some problems and features of using Quickdraw pictures with the Printing Manager. In general, if your application prints Quickdraw pictures, you should read this note.
Introduction
Most applications support Quickdraw pictures to some degree. They will allow you to import or export picture files, as well as using the PICT resource format on the clipboard to support Cut & Paste with other applications. Unfortunately, there are some problems that occur with pictures at print time, and that's what I want to cover here.
You PICT When?
One of the problems that comes up at print time is the use of picture comments. Some applications store their data in a native format, and only create pictures at print time to enable the use of picture comments. For each page of the document, they open a new picture, record the Quickdraw calls that described the document, along with any picture comments they want to use, and finally close the picture. When this is done, they call DrawPicture to print the picture, and then start the whole process over again for the next page.
This method is supported and fully compatible with future system software, but is not required. The Printing Manager spools each page of a document into a Quickdraw picture. Since the Printing Manager already has a picture open, it is totally legal to send a picture comment (via the PicComment call) in between calls to PrOpenPage and PrClosePage without having them recorded in a picture. The Printing Manager has already replaced the StdComment procedure with its own anyway, so the PicComment call will be intercepted and supported correctly by the Printing Manager. If the only reason you are recording into pictures is so that you can use PicComments, you can avoid the overhead at print time by simply sending the comments directly.
Feeling PICT On?
Even if you aren't sending picture comments, you may still need to create a picture at print time. In general, you should try to create any pictures you need prior to calling PrOpen. This is because there is no way to predict how much memory a particular printer driver will require. Instead, you need to make as much memory available as possible. If you are creating pictures with the Printing Manager open, the chances are good that you are using memory you can't afford to waste.
If you need to create a picture with the Printing Manager open, and memory is not a problem, you should still be aware of some potential problems. First of all, keep in mind the Printing Manager receives data from the application by replacing the Quickdraw GrafProcs stored in the GrafPort returned by PrOpenDoc. One of these procedures is the StdComment procedure which is called each time the application calls the Quickdraw PicComment routine. Since the Printing Manager has these routines patched, creating a picture in the Printing Manager's GrafPort can cause problems. If you must create a picture between calls to PrOpenPage/PrClosePage, you should be sure to set the port to a standard Quickdraw GrafPort before calling OpenPicture. Any GrafPort that was created by Quickdraw (as opposed to the Printing Manager) will work fine.
If you do create a picture at print time, you may experience a syndrome we call 'floating picture comments'. That is, calls made by your application to the PicComment routine will be recorded in a different order than you made them. This will usually cause them to effect the wrong part of the picture, and lead to endless confusion. The best solution to this problem is to create any pictures that your application will need before opening the Printing Manager.
Scaling Pictures - Mountains from Mole Hills
Another problem is a basic problem with pictures that seems to show up more at print time. The problem concerns the scaling of pictures using the destination rectangle passed to DrawPicture. This method will work for most pictures, but problems arise with more complex pictures, and for pictures that contain text. The problem is the method that Quickdraw uses to scale the text stored within pictures. When scaling, Quickdraw tries to handle the text scaling intelligently by changing the size of the font being used, as opposed to just scaling the bits. Unfortunately, the widths used by bitmapped fonts are not always linear (ie. the 12 point width isn't exactly 1/2 of the 24 point width). Because of this, you can run into problems with lines of text getting slightly longer or shorter as the picture is scaled. In many cases, the error is insignificant, but if you are trying to draw a line of text that fits exactly into a box (a spreadsheet cell for example), you might be surprised to see the line of text extending beyond the box when the picture is scaled.
There can also be problems when using certain picture comments or imbedded PostScript. In the case of the TextCenter picture comment, you specify an offset to the center of rotation. This offset is usually based on the metrics of the font being used. If you scale the picture, Quickdraw decides to use a different font, and the offset you originally specified will be incorrect.
The easiest way to solve these problems is to scale the picture yourself. Especially if you are trying to scale by a large amount. For example, some applications create a picture at 72 dpi (ie. dots per inch), and then scale it to 288 dpi for printing by simply increasing the destination rectangle by 4x. This is asking a lot of the system, and will result in the text problems described above. Instead, you should either draw the picture into its original frame, and let the Printing Manager handle scaling it to the resolution of the device, or handle the scaling yourself by parsing the picture and playing it back opcode by opcode instead of calling DrawPicture.
One last thing to watch for when scaling pictures is integer overflows. It's usually pretty rare that you will overflow a coordinate when creating a Quickdraw picture, but it is not so hard to do when scaling a picture. For example, some applications will draw something offscreen to make sure the Printing Manager has configured the clip region and other related structures. They usually do this by moving the cursor to (-32767,-32767), and then draw a pixel. This works fine to initialize the Printing Manager, and the pixel isn't actually seen on the output. The problem occurs when you try to scale this picture. If you try to make it bigger, Quickdraw will adjust to coordinate (-32767,-32767) which will end up overflowing. The only way to solve these problems is to look for these kinds of operations in the picture before trying to scale it with DrawPicture.
Pictures Within Pictures–Is Nesting the Best Thing?
One cool feature of Quickdraw pictures is the ability to nest them easily. Basically, you can call OpenPicture, and then call DrawPicture with multiple pictures, and when you call ClosePicture, they will all have been recorded into one picture. Very cool. The problem comes when you start using the Begin/End form of picture comments. There are some comments like PostScriptBegin/PostScriptEnd, and TextBegin/TextEnd that have a begin comment that is followed by an end comment. When using these comments, it is very important to make sure that you have an end for each begin that you have sent. If the nesting gets off, you will, at the least, get incorrect output, though it is more likely that the Printing Manager will actually crash. If your application is generating picture comments, it is very simple to make sure that you have an end for each begin. But when nesting a picture that you have imported from another application, it is important to know how its comments will interact with yours.
In most cases, you can simply call DrawPicture to render the picture to the Printing Manager and you don't have to worry. But if you are creating a picture for export, you may have to nest multiple pictures from multiple creators into the same picture to be exported. If this is the case, it is important to make sure that all of your begin comments have matching end comments before attempting to insert another picture. If this is done, you can insert the imported picture without having to worry about the comments it contains. If all of your begin/ends are matched, you can assume that the imported picture will be just as valid.
On the other hand, if you have a begin comment, and want to insert a picture before inserting the appropriate end comment, you must parse the picture to be inserted to make sure it is not using the same comment pair. If it is, and you insert it, you will have problems.
So make sure that all your begins and ends are matched, and don't try to insert other pictures between begin/end pairs of comments. If you find that you have to insert a picture between a pair of begin/end comments, you must parse the picture to be inserted to make sure that it does not use the same comments.
Penalty for Quickdraw - Clipping
Here's a subtle fact about Quickdraw pictures. If you call OpenPicture, and then record some drawing operations, and you don't explicitly specify a clipping region, Quickdraw will specify one for you. In fact, Quickdraw will use the last clip region stored in the GrafPort that you are using when you call OpenPicture. This has been a surprise to many a developer when they record a picture, and a big piece of it ends up missing when they draw it. This isn't specific to print time, it can happen on the screen too, but it happens enough that it's worth mentioning.
D' Resolution
If you've read Technical Note #275, Features of 32 Bit Quickdraw 1.2, you probably noticed the new font and resolution information. Basically, fonts are now stored in pictures by name, not by ID. This means that fonts stored in pictures will be displayed correctly on any Macintosh without fonts remapping to other faces. The other new addition to the picture format is horizontal and vertical resolution information. Applications that create pictures using the new OpenCPicture call will be able to tell Quickdraw the native resolution of the picture data. So if you're a scanner that is scanning at 200 dpi, you will be able to store your data at 200 dpi (instead of scaling it to 72 dpi first). When an application subsequently opens the picture, it can determine the picture's resolution and take the necessary steps to display it correctly (ie. scaling down for display on the 72 dpi screen, or scaling up for display on 300 dpi devices like the LaserWriter).
Conclusion
Quickdraw pictures can be used successfully at print time, if you avoid the problems described above. Although there is a little overhead required by some of the workarounds, most are very simple to implement, and will help you avoid future compatibility problems.
Further Reference:
• PostScript Language Reference Manual, Adobe Systems Inc.
• LaserWriter Reference Manual, Addison-Wesley
PostScript is a registered trademark of Adobe Systems Incorporated.
PR 22 - pIdle Proc (or how to let users know what’s going on during print time…)
Printing
Written by: Pete “Luke” Alexander April 1991
This Technical Note discusses how to defensively program a pIdle procedure to work with the majority of print drivers in existence today, and how to install it at print time.
Introduction
When using a pIdle procedure at print time, there are a few things that one should remember to be compatible with the printer drivers that are available today. This Technical Note discusses installing a pIdle procedure at the right time and the things to remember when writing one.
Installing The pIdle Proc
Let's start by installing the pIdle procedure at the right time. You must install your pIdle procedure into the print record before calling PrOpenDoc. If you do not install your pIdle procedure before your call to PrOpenDoc, the printer driver does not give the application's pIdle procedure any time. The following code fragments demonstrate installing the pIdle procedure in the right place:
MPW Pascal
<< more print loop would appear above, see Tech Note #161 for details >>
{** Install a pointer to your pIdle proc into your print record. **}
<< more print loop would follow below, see Tech Note #161 for details >>
For a complete printing loop that handles errors at print time and makes all of the right calls to the Printing Manager, refer to Technical Note #161, A Print Loop That Cares...
Things To Remember About pIdle Procedures
It is extremely important to design and code your pIdle procedure as defensively as possible, thereby making sure that it works with as many printer drivers as possible. This section details a few things to remember when creating pIdle procedures.
Saving And Restoring The Current Port
It is extremely important to save the printer driver’s GrafPort, upon entry to your pIdle procedure and restore it upon exit. Why? If you do not, the printer driver would draw into the GrafPort of your dialog box instead of it's GrafPort,which will cause some bad results. To save the printer’s GrafPort, you should call _GetPort when entering your procedure. Before you exit your procedure, you would call _SetPort to set the port from your dialog box back to the printer driver’s GrafPort (i.e., the one you saved with _GetPort).
Saving And Restoring The Printer Driver’s Resources
If the application changes the resource chain within it's pIdle procedure, you want to save and restore the printer driver’s resource chain. Why? Some printer drivers assume that their resource chain does not change, but this may not be true when the driver calls the pIdle procedure installed by the application at print time. To accomplish this task, call _CurResFile, saving the ID of the printer driver’s resource file at the beginning of your pIdle procedure. When you exit from your pIdle procedure, restore the resource chain back to the printer driver’s resource chain with a call to _UseResFile.
At this point, you might be wondering what might change the resource chain. If you called _OpenResFile or _UseResFile (anything that would change the value of the low memory global TopMapHdl) within the application's pIdle procedure, the chain would be changed. If you are not changing the resource chain, these calls would not be needed.
Handling Errors From Within A pIdle Procedure
You should avoid calling PrError within your pIdle procedure; errors that occur while it is executing are usually temporary, and serve only as internal flags for communication within the printer driver—they are not intended for the application. If you absolutely must call PrError within your idle procedure, and an error occurs, never abort printing within the idle procedure itself. Wait until the last called printing procedure returns, then check to see if the error still remains. Attempting to abort printing within an idle procedure is a guarantee of certain death.
Canceling Or Pausing The Printing Process
If you install a procedure for handling requests to cancel printing, with an option to pause the printing process, beware of timeout problems when printing to the LaserWriter. Communication between the Macintosh and the LaserWriter must be maintained to prevent a job or a wait timeout. If there is not any communication for a period of time (over two minutes), the printer times out and the print job terminates due to a wait timeout. Or, if the print job requires more than three minutes to print, the print job terminates due to a job timeout. Since, there is not a good method to determine to what type of printer an application is printing, it is probably a good idea to document the possibility of a LaserWriter timing out for a user who chooses to select “pause” for over two minutes.
Some Printer Drivers Do Not Support pIdle Procedures
Some printer drivers do not support pIdle procedures, as they prefer to handle the pIdle procedure in their own manner without giving an application’s pIdle procedure any time. This situation should not be a problem as long as you do not assume that your pIdle procedure is always called at print time. Therefore, you should only create your pIdle procedure to display the dialog box and respond to a user pausing, continuing, or canceling a print job.
Conclusion
When installing your pIdle proc, it must be installed before the application calls PrOpenDoc. You want to make sure that you save and restore the GrafPort , upon entry and exit of your pIdle procedure, to make sure that the printer driver will image into the correct port during the print job. Finally, if you are changing the resource chain by calling _OpenResFile or _UseResFIle, you want to make sure that you save and restore the resource chain.
Further Reference:
• Inside Macintosh, Volume II, The Printing Manager
• Technical Note M.IM.PrintLoop —
A Print Loop That Cares...
PR 23 - Position-Independent PostScript
Printing
Revised by: March 1988
Written by: Scott "ZZ" Zimmerman
This technical note describes a method for inserting position-independent PostScript into QuickDraw pictures.
There is a problem with pictures that contain PostScript code. Sometimes the PostScript code that is inserted into the picture is dependent on the position of the picture on the page. The problem arises when these pictures are cut or copied from their original position, and pasted into another position or even into another document. The PostScript code will not know the new location of the picture, and will not execute correctly.
The solution for this problem, is to provide some way for the PostScript code to determine the current location of the picture relative to the page that it is being printed on. This is done by inserting QuickDraw calls to position the LaserWriter’s pen before inserting the position dependent PostScript code. When the PostScript in the picture is executed, the LaserWriter’s pen location will be in a location relative to the position of the picture on the page.
The following example illustrates a method for positioning the LaserWriter’s pen before inserting any PostScript code into the picture. The method uses QuickDraw calls to position the LaserWriter’s pen, and will work with any application that supports QuickDraw pictures. Applications do not have to be changed to be able to print pictures which use this technique; normal calls to DrawPicture will work.
The following code fragment will create a picture that contains PostScript to draw a rectangle around the picture’s frame:
FUNCTION CreatePicture(pictureRect: Rect): PicHandle;
(* Kill off the Handle we created and close the picture. *)
DisposHandle(PSHandle);
ClosePicture;
END; (* CreatePicture *)
See the LaserWriter Reference Manual for more information about PicComments. See the PostScript Language Reference Manual for more information about the currentpoint operator.
There are some important guidelines to follow when sending PostScript directly to the LaserWriter. See the PostScript Commands section of Technical Note #91, for a complete description of these guidelines.
Further Reference:
• The Print Manager
• QuickDraw
• LaserWriter Reference Manual
• Technical Note M.IM.PictComments —
Optimizing for the LaserWriter—PicComments
• PostScript Language Reference Manual, Adobe Systems
• PostScript Language Cookbook and Tutorial, Adobe Systems
PR 505 - PostScript Q&As
Printing
Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
PostScript documentation
Date Written: 7/13/90
Last reviewed: 8/1/92
Adobe Systems publishes three great manuals that can help you with PostScript commands: PostScript Language Reference Manual, PostScript Language Tutorial, and PostScript Language Cookbook. You can find these manuals at just about any bookstore, or you can order them through APDA by calling (800) 282-2732 or writing them at:
Apple Computer, Inc.
20525 Mariani Avenue, Mail Stop 33-G
Cupertino, CA 95014
AppleTalk packets and PostScriptHandle PicComment
Date Written: 8/7/90
Last reviewed: 8/1/92
What’s the optimal amount of PostScript to pass in PicComment 192 for AppleTalk packet throughput?
___
There is no one optimal size that your PostScriptHandle PicComment should be for AppleTalk packets. The LaserWriter driver sends different amounts of PostScript, depending on the amount of memory that is available. It could send as little as 1K or as much as 4K bytes of PostScript at one time. The driver is using four 4096-byte buffers to send the data, and the amount of data that it sends from a particular buffer is completely memory dependent. In the general case, it does not send any data until a particular buffer is full. The driver does not control the number of packets that are sent over AppleTalk. When PAP receives the PostScript, it packages up the PostScript and sends it down to the LaserWriter. In general, DTS recommends that applications send a PostScript handle that contains 4096 bytes of data.
Using PostScript to control LaserWriter serial I/O
Date Written: 12/6/90
Last reviewed: 3/28/93
Where can I find information on using PostScript to control a multi-tray sheet feeder by communicating through the LaserWriter serial port?
___
You need to talk with Adobe on how they control the serial chip with PostScript. They use some undocumented PostScript calls to control the serial chip on the controller board of the LaserWriter. They can be reached at:
Adobe Systems, Inc.
1585 Charleston Road
Mountain View, CA 94039
or
AppleLink Address: ADOBE.SUPT (Tech Support)
Details about installing feeder resources for Macintosh into the LaserWriter driver 7.0 dialogs are available in the Macintosh Technical Note “Feeder Fodder.”
How to inhibit LaserWriter test page
Date Written: 12/24/90
Last reviewed: 8/1/92
How do I inhibit the test page on a LaserWriter?
___
1. Use the LaserWriter Utility to turn the startup page off (best), or
2. Download the following PostScript commands:
serverdict begin 0 exitserver
statusdict begin
false setdostartpage
end
The above commands can be downloaded from your Macintosh to the printer several ways:
1. Use the menu command in the LaserWriter Utility that comes with System 7 (easiest).
2. You can use a PostScript utility like LaserTalk from Emerald City Software.
3. The PostScript Language facility in Microsoft Word.
4. PSDump or PSsend
5. Use the PostScript utilities in the Developer CD’s PostScript Utilities folder.
6. Use the methods described in the Macintosh Technical Note #91.
When you issue the commands, your LaserWriter will probably crank and grind for a few seconds (it has to re-program the EPROM inside) then after the lights stop flashing, your LaserWriter will no longer spit out the startup page until you enable the setdostartpage flag again (in other words, this isn’t a permanent change).
For more information on the above subject we recommend the PostScript Language Reference Manual by Adobe Systems.
Where to find Encapsulated PostScript file (EPSF) documentation
Date Written: 4/5/91
Last reviewed: 8/1/92
I’m developing an application that creates pictures containing both QuickDraw and PostScript (as picComments). How do I create an encapsulated PostScript file (EPSF)? Is the format explained anywhere, and is it possible to convert the QuickDraw into PostScript directly in the application?
___
Adobe’s EPSF format is documented in the new (2nd) edition of Adobe’s PostScript Language Reference Manual (Addison-Wesley) and in “Adobe Document Structuring Conventions,” available from Adobe Systems. Adobe’s references explain how to structure your comments in your PostScript file so that other applications know how to read it.
You probably don’t want to try to convert QuickDraw to PostScript directly in your application, although it is possible. Basically, it involves translating each QuickDraw command into PostScript, which is what the LaserWriter Driver does. It’s a lot of work and makes you dependent on the QuickDraw features being used, which can be a problem when new features are added.
PostScript setprintername doesn’t accept colons in string
Date Written: 4/16/91
Last reviewed: 8/1/92
Why can’t I use a colon with the PostScript command setprintername to change the Personal LaserWriter NT network name and type, but it works with the LaserWriter II?
___
The reason that the Personal LaserWriter NT is not accepting the PostScript you’re sending is not because of a bug, but rather a bug fix. Colons have never been acceptable in the string passed to setprintername. (See page 296 of Adobe’s PostScript Language Reference Manual.) The reason the call works in older LaserWriters but not the Personal LaserWriter NT is that the NT has a newer version of PostScript in it. Older versions of PostScript didn’t enforce Adobe’s printer naming conventions. The setprintername restrictions have been enforced in more recent versions, however. Therefore, colons are not allowed.
If you need to change the LaserWriter network type, it can be done with the AppleTalk-type parameter described on page 105 of Apple’s LaserWriter Reference manual. This method will work on the new printers as well as the old.
PostScript code for renaming LaserWriter
Date Written: 6/5/91
Last reviewed: 8/1/92
In checking a printer name to ensure an even number of characters, does the LaserWriter Namer append a space to the end if the total is odd?
___
In a nutshell, yes. The Namer does indeed append an extra space to odd-length printer names. The reasoning behind this is to be compatible with some of the old 68000 processors. The addressing scheme of these old processors requires that memory be accessed by even-numbered addresses. To get at a piece of memory located after an odd-length LaserWriter name, you would need to get an odd-numbered address (which is not directly possible). This obviously can be worked around, but the authors of the Namer felt it best to avoid this altogether by padding the name when necessary. It’s worth noting that the version 7.0 Namer does this too.
If you’d like to work around this, here’s an alternate method for renaming the printer:
The printer name is stored as a string in the persistent parameters of all LaserWriters. This string can be changed by the following PostScript program:
serverdict begin 0 exitserver
statusdict begin (NEWNAME) setprintername
Replace NEWNAME with the name you want for the printer. The name can be up to 31 characters and should consist entirely of printing characters--the “@” and “:” cannot be used. Note that parentheses are required.
This program can be downloaded to the LaserWriter in batch or interactive mode. In interactive mode you should type both command strings on the same line before pressing Enter, because exitserver disconnects you from the printer. When you reestablish your connection to the printer, the name will be changed.
Make sure you have selected the correct LaserWriter using the Chooser before downloading this program, so you don’t rename the wrong LaserWriter.
Printing 2-byte bitmap fonts on PostScript LaserWriters
Date Written: 9/29/91
Last reviewed: 8/1/92
The Macintosh Technical Note #91 refers to using QuickDraw picComments to print rotated text, but this doesn’t work for 2-byte Japanese text. Is there a recommended workaround for this problem?
___
Two-byte characters don’t print when using the TextBegin, TextCenter, and TextEnd PicComments because of the structure of the data that is being sent in the comments. The LaserWriter driver uses these PicComments to rotate text, and it is not expecting the data to be in the 2-byte format. The 2-byte format is converted to bitmap data by the driver, so the data is ignored and nothing is printed. The driver is expecting the comments to contain “normal” text.
Since the data is in bitmap format, you can use the RotateBegin and RotateEnd PicComments to perform the rotation, as follows:
RotateBegin
DrawString (...); << To rotate your 2 byte Japanese characters
RotateEnd
The tricky part of the solution is that you only need to use this approach when you’re printing 2-byte Japanese bitmap fonts. Therefore, you’ll need to check the type of data that is to be printed, and send the appropriate PicComments.
You can also use the following PicComments to hide the QuickDraw representation of the rotated text, as shown below:
PostScriptBegin
CopyBits (...); << For the QuickDraw printers
PostScriptEnd
The PostScriptBegin and PostScriptEnd PicComments are used to hide the CopyBits calls from the LaserWriter driver in a device-independent manner. When you use PostScriptBegin, the LaserWriter driver doesn’t interpret any QuickDraw calls until it finds the PostScriptEnd PicComment. Since QuickDraw printer drivers do not understand the PostScriptBegin and PostScriptEnd PicComments, they ignore the PicComments, and the CopyBits call is used to perform the rotation of your text.
There is one problem with the previously mentioned solution: If you record the previous PicComments into a picture and print it, everything will print exactly as expected, but if you display the picture into a window, you’ll see the unrotated version of the text. This is definitely a bug, which has been reported, but it won’t be fixed in the very near future. So, what do you do in the meantime? You have the following two options:
1) Do not export pictures that contain this type of rotated data.
2) Export the picture with this problem, and explain the problem to your users.
Neither solution is ideal. Quite a few applications out in the market today have decided to use idea #2.
Macintosh spooling should be device independent
Date Written: 1/1/90
Last reviewed: 8/1/92
How can I tell whether the chosen printer supports PostScript or not?
___
There is no supported method for determining whether or not a device speaks PostScript. Apple engineering would like all Macintosh applications to spool both PostScript and QuickDraw regardless of the chosen printer, so that the spool file is device-independent and can be redirected after spooling. Since engineering is strongly encouraging developers to spool both models, it is doubtful that Apple will be providing a query mechanism in the future. The best method is to assume PostScript is available, and format your document based on information returned by PrGeneral and the print record.
LaserWriter driver and PostScript showpage
Date Written: 1/1/90
Last reviewed: 6/14/93
When I print a PostScript file, why do I get one blank page for every page printed?
___
Your PostScript file probably contains calls to the PostScript showpage operator. This operator is also called by the Macintosh LaserWriter driver when it receives the PrClosePage call. The solution to this problem is to strip showpage calls from the file before sending the file to the LaserWriter. If you send one QuickDraw graphic at the beginning of each page,
MoveTo(-32000, -32000);
Line(0, 0);
the LaserWriter driver will handle calling showpage for you. Versions of the LaserWriter driver before 5.2 do not send the showpage operator unless a QuickDraw drawing routine (that is, something other than PicComment) is sent. This is why you need to do the MoveTo/LineTo. Versions 5.2 and later will send the showpage operator whether any QuickDraw has been sent or not. Since you can’t be sure whether showpage will be sent for you or not, the best solution is to let the LaserWriter driver send it.
PicComment TextIsPostScript versus PostScriptHandle
Date Written: 1/1/90
Last reviewed: 6/14/93
When using the Macintosh TextIsPostScript picture comment, my PostScript code is also “printed” on the ImageWriter. Why isn’t it ignored?
___
One of the comments, TextIsPostScript, allows the application to use the QuickDraw DrawString procedure to send the PostScript code. This method is no longer recommended, as it is not device independent. If you use the TextIsPostScript comment when printing to a non-PostScript device, the PostScript code will be printed as text. On an ImageWriter, the entire PostScript program will be printed as one line on the page, because the TextIsPostScript PicComment is ignored by the ImageWriter drivers, and the DrawString calls are executed normally.
To avoid this problem, developers should use the PostScriptHandle comment. This comment accepts a handle as a parameter. The handle points to the PostScript code that you want to download. This comment is better for two reasons:
First, there is no QuickDraw/PostScript interaction. For example, early versions of the LaserWriter driver sent the strings passed to DrawString as-is. The latest version of the driver appends carriage returns onto those strings. If your application is expecting the DrawString calls to work one way or another, you might get a surprise.
The other reason for using the PostScriptHandle comment involves device independence. When a non-PostScript driver sees the PostScriptHandle PicComment, it not only ignores the comment, but also ignores the PostScript data that was passed to the comment, so nothing prints if you use the PostScriptHandle comment on a non-PostScript driver.
X-Ref:
Macintosh Technical Note “How To Produce Continuous Sound Without Clicking”
How to send PostScript from the Macintosh to the LaserWriter
Date Written: 5/3/89
Last reviewed: 6/14/93
How do I send PostScript from the Macintosh to the LaserWriter?
___
The best method for sending PostScript to the LaserWriter is to use the PostScriptHandle (kind = 192) PicComment documented in the Macintosh Technical Notes “Optimizing for the LaserWriter” and “Picture Comments—the Real Deal.” There are a few PicComments for sending PostScript to the LaserWriter, but the easiest to use and most problem free is the PostScriptHandle comment. One model is:
PrOpenPage(...)
{ Send some QuickDraw so that the Printing Manager gets a }
The described fragment prints a line on any type of printer, PostScript or not. The first MoveTo/Line combination is required to give the LaserWriter driver a chance to define a clipping region. The LaserWriter driver replaces the grafProcs record in the GrafPort returned from PrOpenDoc. In order for the LaserWriter driver to get execution time, you must execute a QuickDraw drawing routine that calls one of the grafProcs. In this case, the MoveTo/Line combination is sent firing the StdLine grafProc. When StdLine executes, it notices that the GrafPort has been reinitialized, and therefore initializes the clipping region for the port. Until the MoveTo/Line combination is executed, the clipping region for the port is set to (0,0,0,0). If PostScript code is sent via the PostScriptHandle PicComment before executing any QuickDraw routines, all PostScript operations will be clipped to (0,0,0,0). The next thing to do is send the PostScriptBegin PicComment. This comment is recognized only by PostScript printer drivers. When the driver receives this comment, it saves the current state of the PostScript device (by executing the PostScript gsave operator), then disables all QuickDraw drawing operations. This way, the QuickDraw representation of the Graphic will be ignored by PostScript devices. In the previous example, the MoveTo/LineTo combination is only executed on non-PostScript devices. The next comment is the PostScriptHandle PicComment. This tells the driver that the data in thePSHandle is to be sent to the device as PostScript code. The driver then passes this code unchanged to the PostScript device for execution. The PostScriptHandle PicComment is only recognized by PostScript printer drivers. The last PicComment, PostScriptEnd, tells the driver to restore the previous state of the device (via a PostScript grestore call), and to enable QuickDraw drawing operations. Since all PicComments are ignored by QuickDraw devices, only the QuickDraw representation is printed. Since PostScriptBegin tells PostScript drivers to ignore QuickDraw operations, only the PostScript representation is printed on PostScript devices. This is a truly device-independent method for providing both PostScript and QuickDraw representations of a document.
Converting PostScript file to Encapsulated PostScript
Date Written: 5/19/92
Last reviewed: 6/14/93
What needs to be added to an ordinary PostScript file to convert it to an Encapsulated PostScript (EPS) file?
___
The latest Adobe “red book,” PostScript Language Reference Manual (2nd Edition), has the information you need. Appendix H: Encapsulated PostScript File Format Version 3.0 describes the contents of an EPS file. Appendix G: Document Structuring Conventions specifies the single-page document PS file, which must include at least these two comments:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: llx lly urx ury
You might find the following references from Adobe useful as well:
Adobe Illustrator Document Format Specification v2.0 (Adobe Technical Note #LPS5007)
Macintosh Technical Note “Picture Comments—The Real Deal” (formerly #91) contains sample code for using all of the supported Picture Comments.
Printing halftone images on the LaserWriter
Date Written: 5/3/89
Last reviewed: 8/1/92
How can I print halftone images on the LaserWriter? How do I use the PostScript “image” operator for printing halftones?
___
The PostScript “image” operator is similar to the Macintosh QuickDraw CopyBits routine. It can be used by converting a QuickDraw bitmap/pixmap into an image call. This is only necessary if you are printing color information with a PostScript printer driver that doesn’t support Color QuickDraw. LaserWriter drivers up to 5.2 do NOT support Color QuickDraw. If you want to send color information to a LaserWriter with version 5.2 of the driver, you will have to convert your color images into image commands. Before doing this it is important to check the GrafPort returned by PrOpenDoc. If this port is a Color QuickDraw port (for example, portBits.rowBytes < 0) then you should use Color QuickDraw commands and let the driver handle the conversion to PostScript.
About image: The PostScript image operator is used to send bitmaps or pixmaps to the LaserWriter. The image operator can handle depths from one to eight bits per pixel. Our current LaserWriters can image only about 16 shades of gray, but the printed page will look like there’s more. Because the image operator is still a PostScript operator, it expects its data in the form of hexadecimal bytes. The bytes are represented by two ASCII characters(“0”-”9,” “A”-”F”) per byte. The image operator takes these parameters: width height depth matrix image-data
The first three are the width, height, and depth of the image, and the matrix is the transformation matrix to be applied to the current matrix. See the PostScript Language Reference Manual for more information. The image data is where the actual hex data should go. Instead of inserting the data between the first parameters and the image operator itself, it is better to use a small PostScript procedure to read the data starting right after the image operator. For example:
In the preceding example, the width of the image is 640, the height is 480, and the depth is 8. The matrix (enclosed in brackets) is set up to draw the image starting at QuickDraw’s 0,0(top left of page), and with no scaling. The PostScript code (enclosed in braces) is not executed. Instead, it is passed to the image operator, and the image operator calls it repeatedly until it has enough data to draw the image. In this case, it is expecting 640*480 bytes. When the image operator calls the procedure, it does the following:
1. Pushes the current file which in this case is the stream of data coming to the LaserWriter over AppleTalk. This is the first parameter to the readhexstring operator.
2. Pushes picstr. picstr is a string variable defined to hold one row of hex data. The PostScript to create the picstr is:
/picstr 640 def
3. readhexstring is called to fill picstr with data from the current file. It begins reading bytes which are the characters following the image operator.
4. readhexstring leaves the string we want, and a boolean that we don’t want, on the stack, so we do one pop to kill off the boolean. Now the string is left behind for the image operator to use.
Using the above PostScript code you can easily print an image. Just fill in the width height and depth, and send the hex data immediately following the PostScript code.
Setting up for image: Most of the users of this technique are going to want to print a Color QuickDraw pixmap. Although the image command does a lot of the work for you, there are still a couple of tricks for performance:
Assume the maximum depth: Since the current version of the image operator has a maximum depth of eight bits/pixel, it is wise to convert the source image to the same depth before imaging. You can do this very simply by using an offscreen GrafPort that is set to eight bits/pixel, and then using CopyBits to do the depth conversion for you. This does a nice job of converting lower resolution images to 8 bits/pixel.
Build a color table: An eight bit deep image can use only 256 colors. Since the image that you are starting with is probably color, and the image you get will be grayscale, you need to convert the colors in the source color table into PostScript grayscale values. This is actually easy to do using the Color Manager. First create a table that can hold 512 bytes. This is two bytes for each color value from 0 to 255. Since PostScript wants the values in ASCII, you need two characters for each pixel. Now loop through the colors in the color table. Call Index2Color to get the real RGB color for that index, and then call RGB2HSL to convert the RGB color into a luminance value. This value is expressed as a SmallFract which can then be scaled into a value from 0 to 255. This value should then be converted to ASCII, and stored at the appropriate location in the table. When you are done, you should be able to use a pixel value as an index into your table of PostScript color values. For each pixel in the image, send two characters to the LaserWriter.
Sending the data: Once you have set up the color table, all that’s left to do is loop through all of the pixels, and send their PostScript representation to the LaserWriter. There are a couple of ways to do this. One is to use the low-level Print Manager interface and stream the PostScript using the stdBuf PrCtlCall. Although this seems like it would be the fastest way, the latest version of the LaserWriter driver (5.0) converts all low-level calls to their high level equivalent before executing them, so the low-level interface is no longer faster than the high level. Another way is to use the high-level Print Manager interface, and send the data via the PostScriptHandle PicComment. This enables you to buffer a large amount of data before actually sending it. Using this second technique, you should be able to image a Macintosh II screen in about 5 minutes on a LaserWriter Plus, and about 1.5 minutes on a LaserWriter II NTX.
X-Ref:
PostScript Language Reference Manual, Adobe Systems.
PR 510 - Printer Driver Q&As
Printing
Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As in this Technical Note:
Defining default LaserWriter Pro paper tray
Code for getting selected printer name
StyleWriter II driver differences
Determining printer font
Defining default LaserWriter Pro paper tray
Date Written: 5/17/93
Last reviewed: 5/19/93
How can I set the default paper tray on my LaserWriter Pro to something other than the 250-sheet cassette?
___
The paper tray selection in the printing job dialog is not “sticky”; it’s not preserved from job to job. In LaserWriter 7.2, the choice of one of the two paper trays is stored in the print record. You may be able to hack out where this is stored and define a new “default” print record by changing the PREC(0) resource, but this is completely unsupported and you do so at your own risk.
In LaserWriter driver 8.0, the default paper trays are defined in the PostScript Printer Definition (PPD) file. If you’re sufficiently adventurous, you can edit the PPD file for your printer to change these relationships. LaserWriter 8.0 requires files that meet the PPD 4.0 specification, available from Adobe’s Developer Support program.
Code for getting selected printer name
Date Written: 3/10/93
Last reviewed: 6/24/93
How do I get the name of the currently selected printer, for Systems 6 and 7?
___
The printer driver has a resource of type PAPA, ID -8192, which contains the name of the selected printer and the network object type. This resource is amazingly easy to get; you don’t even need to know where the printer driver resource file is located. Just call PrOpen. The Printing Manager will open the currently selected printer driver for you, and place it at the top of the resource chain. Then see whether you can GetResource for 'PAPA' ID -8192, and viola—you have a handle to the printer name.
This will work under both System 6 and System 7. However, under QuickDraw GX, this method is subject to change. Also note that this is a read-only field; changing it doesn’t necessarily change the selected printer.
The printer name is the first string, and the object type is packed right up against it. If all you want is the name, then here’s a C routine that will provide it:
My application won’t print to a StyleWriter II although it works fine on all other printers including the original StyleWriter. Can you give me any suggestions? What’s different about the StyleWriter II?
___
The StyleWriter II driver is a member of the “GrayShare” driver family, with new features such as support for grayscale printing (if Color QuickDraw is available) and printer sharing over the network. Its internal architecture is very different from previous printer drivers. In spite of thorough compatibility testing, some problems have shown up since the first release. In many cases, the driver revealed weaknesses in the applications themselves; for some other problems, a solution will be incorporated in the next release of the driver. Here are currently identified problem areas with the StyleWriter II driver:
• The StyleWriter II driver handles memory differently. For example, if an application has a dereferenced handle to an unlocked block while CopyBits’ing into the printing port, this may work fine on all other printer drivers, but the block is likely to move with the StyleWriter II driver, and the results are unpredictable.
• The StyleWriter II driver maintains its own A5 world internally. If an application installs a growZone proc and forgets to set up its own A5 in the growZone proc (ignoring the Technical Note “Register A5 Within GrowZone Functions”), the growZone proc may get called with the StyleWriter II driver’s A5, which obviously is bad for the survival of both the application and the printer driver.
• The StyleWriter II driver calls the pIdleProc (in the job subrecord of the print record) more often than other printer drivers; in particular, it may be called during execution of PrOpenDoc. If an application reloads a print record previously used, containing an old (now invalid) pointer to an idleProc, and doesn’t update the pIdleProc field before calling PrOpenDoc, disaster is very likely. Note that the TechNote “pIdle Proc (or how to let users know what’s going on during print time)” recommends installing the idleProc before PrOpenDoc.
• Like most other QuickDraw printer drivers, the StyleWriter II driver uses algorithms built into QuickDraw for rasterizing picture elements like ovals and arcs, but not necessarily with the same sequence of coordinate transformations. Because of the 360 dpi resolution, internal computations with the transformed coordinates may hit the 16-bit integer limitation of QuickDraw, and reveal bugs in the old QuickDraw routines that have never been discovered so far.
• The StyleWriter II driver (version 1.0) contains STR# resources with positive ID numbers that may conflict with STR# resources in an application. This will be fixed in the next release of the driver.
• Under certain circumstances, the StyleWriter II driver seems to have trouble with a PmForeColor call. This is under investigation and will be fixed.
Determining printer font
Date written: 1/26/93
Last reviewed: 4/26/93
Our application must print with Helvetica if available, and Geneva if not. How can I determine which fonts are available in a printer? I’ve been using the wDev field in the print record and assuming that a value of 3 means Helvetica will print correctly, but according to “Print Hints: Top 10 Printing Misdemeanors” in develop issue 12, this isn’t dependable.
___
There’s no procedural way to ask a printer if it even has built-in fonts, let alone what they are. By using wDev == 3, you’ve been assuming that all PostScript printers have built-in Helvetica fonts, and while most do, some do not. There are several things you can do, though.
First of all, you should know about font substitution. If this option is checked in the LaserWriter driver (it’s checked by default), you’ll get Helvetica instead of Geneva when drawing in Geneva on PostScript printers that have Helvetica. The driver adjusts all the font metrics so the widths match what you see on the screen. In some versions of the LaserWriter driver, you’ll get Geneva instead—but only if the Geneva TrueType font is available, so you get excellent quality either way. This might be enough to solve your entire problem.
If not, there’s the new PSWriter driver on AppleLink and on the Developer CD Series disc. PSWriter uses PostScript Printer Definition (PPD) files and supports a new PrGeneral call that lets you obtain the PPD file so that you can know things about your target printer, including what fonts are installed. While this might give misleading results if the user has never set up the printer (and is using the Generic PPD), it should be just fine in all other cases.
There’s no way to tell whether the user has downloaded a font to the PostScript printer, making it available, because it won’t be in the PPD file and there’s no way to ask the printer.
Where to get PostScript Printer Definition (PPD) files
Date written: 2/9/93
Last reviewed: 4/1/93
Where can I get PostScript Printer Definition (PPD) files for Apple’s PostScript printers?
___
Apple recently made PPD files for its printers—past and present—available. You can find them on AppleLink in the Software Sampler: Apple SW Updates: Macintosh: Printing Software: PPDs folder.
PPD files for non-Apple PostScript printers with ROMs by Adobe Systems are available from a clearinghouse maintained by Adobe. To request a PPD file from Adobe, send an internet message to “ps-file-server@adobe.com” with the subject “help”. Adobe’s list server will respond with mail about items available on the list server and how you can get them.
LaserWriter Driver 7.2 isn’t ColorSync aware
Date written: 1/11/93
Last reviewed: 4/1/93
Is LaserWriter Driver 7.2 ColorSync aware?
___
No, LaserWriter Driver 7.2 isn’t ColorSync aware. Apple plans to add ColorSync capability to future versions of the LaserWriter driver, but we don’t have any more information or details than that.
Printing nonstandard page dimensions
Date written: 1/14/93
Last reviewed: 6/14/93
How do we override the standard page dimensions for the StyleWriter or, for that matter, any other printer? We want to print 5.5" x 8.5" (half letter-sized) pages.
___
The current printing architecture isn’t designed for elegant (or sometimes any) communication from your program to the printer driver. All the calls you normally make (such as PrOpenDoc, PrOpenPage, and PrPicFile) are handled by the printer driver and not by the Printing Manager. The drivers manage the print records, put up the dialog boxes, decide how to render graphics and everything else in between. That’s why writing a printer driver is so hard.
If you want to tell a printer driver “I want to use this size paper,” that driver has to implement a driver-specific way to do it or it can’t be done. There’s no PrSetPageSize call in the current printing architecture. In fact, trying to print outside the rPage rectangle can cause physical damage on some printers, so customizing page sizes is not something you want to enter into lightly.
You can’t change the paper size in the print record, because most drivers don’t look there to see what size you want; instead they tell you what size you get in that field. The same is true for most of the print record: Unless Inside Macintosh tells you that you can write to that field, you can’t (or doing so won’t do any good).
The StyleWriter in particular has very limited paper options; it handles letter, legal, A4, and B5 paper sizes—and that’s it. If you try to print other sizes, the hardware reports an error. This is pretty common in these days of very low-cost high-quality printers; features that you as a programmer would want are jettisoned to keep the cost down. Most low-cost laser printers have limited paper-handling capabilities as well. If you try to print continuous feed paper on a StyleWriter, you’ll get a paper jam error after about 15 inches of paper pass through (long enough for the printer to realize it’s not legal-sized paper). Your half-letter size pages are too short for the printer to use.
While QuickDraw GX has a much more robust printing architecture, that doesn’t help right now for the current world. Something that you may wish to consider is making forms available on regular letter-sized paper, with two per sheet. That size paper works in every printer sold in the United States and could be perforated and detached by the customers.
All of Apple’s LaserWriter printers have excellent paper handling but cost relatively more. The best way to handle custom page printing across all printers is to place your custom-sized image on an 8.5" x 11" page and provide special paper.
Many, but not all, of Apple’s printers support a PREC 3 resource that contains extra page sizes in a custom format. The format of this resource is as follows:
PageSizeRecord = RECORD
numItems: INTEGER;
botRights: ARRAY [0..NumPageOptionsZB] OF Point;
titles: PACKED ARRAY [0..0] OF CHAR;
END;
numItems is the number of page sizes displayed in the dialog. The maximum number is six (since there is only room for six radio buttons in the Page Setup dialog). botRights is an array of points specifying the bottom right corner for each page. This corner is specified in 120ths of an inch, and it should define the physical size of the paper, not the imageable area. For example, U.S. Letter is specified as:
bottom = 1320(11"), right = 1020(8.5").
titles is a packed array of page size names. Each name begins with a length byte, followed by the number of characters specified by the length byte. The strings are packed, so string1[LENGTH(string1)+1] would reference the length byte of string2.
To use this mechanism, your application should create a PREC resource with an ID = 4. You can do this very easily by copying PREC(3). Once you have a copy, you can modify the page sizes as you wish. When the printer driver is called to display the Page Setup dialog, it will first look for PREC(4). If found, it will use it to define the page sizes. If not found, the driver will use the standard sizes in PREC(3).
This method only works with some of Apple’s drivers; the LaserWriter driver ignores these resources. If you decide to implement this feature in your application, be sure to warn your users that custom page sizes may not be available on all devices.
Use this feature at your own risk; it’s very likely not to work under QuickDraw GX and later system software.
The userdict definitions in my LaserWriter driver 'feed' resource (written per the Macintosh Technical Note “Feeder Fodder”) get wiped out after each page. At least, every time my redefined showpage is executed the variables that should have been defined the first time in userdict are unbound. What could be happening here? How should I define something in 'feed' resource code that acts like a global variable for a redefined showpage?
___
Your operators shouldn’t be wiped out with each page. You’re being loaded before the PREC 103 is loaded and before the series of save and restore operators are called, which could otherwise wipe you out. Please read the Macintosh Technical Note “The Lo Down on Dictionary Downloading” for a robust description of this process. Thus, we must look to other reasons why your operators are being wiped out.
The natural culprit is your PostScript. Are you wiping yourself out? Second, you should heed the warning on page 4 of the “Feeder Fodder” Technical Note: “As always, calling or redefining operators defined by the LaserPrep (md) dictionary isn’t supported.” You could see problems as you describe if you’re redefining LaserPrep dictionary commands. Other variables include the system software and LaserWriter driver versions that you’re using. It could be an issue with the type of LaserWriter itself.
LaserWriter driver doesn’t SwapMMUMode for 32-bit addresses
Date written: 11/17/92
Last reviewed: 6/14/93
When I use CopyBits to move a cGrafPort’s portPixMap to another cGrafPort (my printing port), it works like a charm when background printing is turned on, but when CopyBits gets called with background printing turned off, the image that prints isn’t the image at all. Why is this happening?
___
You should be aware that since you’re copying the pixels directly from the screen, the baseAddr pointer for the screen’s pixMap may be 32-bit addressed. In fact, with 32-Bit QuickDraw, this is the case. This in itself isn’t a problem, since CopyBits knows enough to access the port’s pixMap’s baseAddr in 32-bit mode, as follows:
mode = true32b;
SwapMMUMode(&mode); // Make sure we're in 32-bit addressing mode.
// Access pixels directly; make no other system calls.
SwapMMUMode(&mode); // Restore the current mode.
That’s how you’d normally handle things if you were accessing the pixels directly yourself. Unfortunately, the LaserWriter driver doesn’t know enough to do the SwapMMUMode and instead ends up copying garbage (from a 32-bit pointer stripped to a 24-bit pointer).
So why does background printing work? Because when you print in the background, everything is rolled into a PICT, which the driver saves off for PrintMonitor. Since the driver is using the standard QuickDraw picture bottlenecks to do this, and CopyBits knows to swap the MMU mode before copying the data into the picture, everything works great. Later, at PrintMonitor time, the picture is played back. Since the data is no longer 32-bit addressed, the LaserWriter driver doesn’t have to call SwapMMUMode to do the right thing; it can just play the picture back.
The solution we propose for you is something similar. At print time (before your PrOpenPage call), call OpenPicture, copy the data from the screen with CopyBits, call ClosePicture, and then call DrawPicture within your PrOpenPage/PrClosePage loop. That should do the trick.
Note that copying bits directly from the screen is not something we recommend. Unless you have no alternative, you should always copy from the original source of the data instead.
System 7.1 and printer driver compatibility
Date written: 11/18/92
Last reviewed: 6/14/93
If a user upgrades from System 7.0.x to 7.1, a new version of the PrintMonitor is installed. Will existing printer drivers behave correctly with the new PrintMonitor?
___
When a user installs System 7.1, Easy Install will update any existing printer software. If the user picks Customize, he or she must choose the printers to be updated. Only the versions of the printer drivers that come with System 7.1 should be used with 7.1. Mixing and matching is bad.
Since only Apple’s printer drivers use PrintMonitor, as long as you upgrade to System 7.1 by using the Installer there’s no issue at all.
System 6 and System 7 PrintMonitor
Date written: 11/18/92
Last reviewed: 3/1/93
Is the version of PrintMonitor that ships with System 7.1 compatible with System 6? If so, which version of the Backgrounder file would be compatible for installation with the System 7.1 PrintMonitor on System 6.x systems?
___
Only Apple’s printer drivers should be using PrintMonitor—the interface is undocumented and unsupported for other printer drivers. PrintMonitor-like things are a different story, but the specific Apple product PrintMonitor works only with Apple’s printer drivers.
While the drivers may be used under System 6, users should use the versions of Backgrounder and PrintMonitor present on the System 6.0.8 disks. Since Backgrounder and PrintMonitor are tied together, we have to recommend against using the 7.1 PrintMonitor under System 6.
Note that in all these cases, nothing was specifically added to make things not work under System 6—they simply weren’t tested and therefore can’t be supported.
Summary:
System 6: Backgrounder and PrintMonitor from 6.0.8, current driver
System 7: Use whatever the Installer installs.
Which printers to test printing
Date written: 10/1/92
Last reviewed: 11/2/92
We need to know what printers on which to test our application. It prints only pixmaps. It’s been tested on some LaserWriters. The question is, how many brands and models of printers do we need to test it on? Are there any definitive printing tests (for example, does success on a LaserWriter indicate correctness of the application)?
___
Unfortunately, there is no such thing as a universal printing test suite. Moreover, successful printing not only depends on the specific printer driver (and its version), but also on the available memory at print time, and on things like the font configuration in the system. (Given that you print pixmaps only, the last comment is not applicable. Most certainly, all potential problems will rather boil down to out of memory conditions). Also, we have seen applications with severe defects in their printing code print quite correctly to the LaserWriter, and fail only on a few other specific printers. Most other printing problems have to do with assumptions about the inner working of a specific printer driver, such as hacking the print record behind the back of the Printing Manager. In this case, trouble with at least one of the 150 plus different printer drivers out there is guaranteed!
Pragmatically speaking, you may want to test printing in priority on the printers most likely being used by your customers. Currently (as of November 1992), this is the PostScript LaserWriter (driver version 7.1.2 or later), the StyleWriter (driver version 7.2.2), the Personal LaserWriter LS (driver version 7.2), and one or another of the most popular third-party printers. In addition, we recommend that you test both on an older LaserWriter (up to the LaserWriter IInt), and the newer ones (LaserWriter IIf, IIg, NTR), because of the differences in the PostScript interpreters and gray-level support.
Where to get documentation on writing a Macintosh printer driver
Date Written: 4/9/91
Last reviewed: 8/1/92
Where can I find documentation on how to write a Macintosh printer driver equivalent to the ImageWriter or LaserWriter driver? In particular, how are Printing Manager and QuickDraw commands translated into calls to the printer driver?
___
DTS’s “Learning to Drive” document and “StdFileSaver” source code, available in AppleLink’s Developer Support folder and on the latest Developer CD Series disc, are helpful references.
Writing a Macintosh printer driver
Date Written: 5/3/89
Last reviewed: 8/1/92
I have a printer I would like to connect to the Macintosh. Where can I find information on writing a printer driver?
___
A Macintosh printer driver is more than a standard device driver. A printer driver contains code to implement all of the standard Macintosh Printing Manager routines. The code includes routines like PrOpen/PrClose, and PrOpenDoc/PrCloseDoc. A Printing Resource File contains all of the resources (including code) to implement the Macintosh Printing Manager for a particular device. A driver works best with all Macintosh applications if it supports both the high- and low-level Printing Manager interfaces, as well as the PrGeneral (IM V:410) routine and its associated opcodes.
Apple is not currently supporting the development of Chooser-selectable device drivers, at least not those that support printers. There are many reasons for this, and here are at least a few of them:
First, there is no documentation or examples available. Each of the Apple printer drivers is unique. They are all written almost entirely in 68000 assembler, and consequently, are not very easy to read. Since each driver is different, the only real documentation for how the drivers work is the source code to the driver. There is some general interface information available, but important information, like how the driver manages its print record, is described only in the source code. This information could be extracted and distilled into some kind of document, but this brings up the next problem:
The Macintosh Printing Manager is currently being revised and enhanced. These revisions will require major changes to the architecture of the Printing Manager. It’s not clear what effect these changes will have on existing printer drivers, but it is very possible that the drivers that exist today will have to be revised significantly to run under the new Printing Manager.
Apple is designing and implementing the next generation Macintosh Printing Manager. Developers’ suggestions for features are being taken into account. One of the goals of the new architecture is to make writing drivers much simpler, and to allow the sharing of code between drivers. When this architecture becomes available, Apple will reconsider its position of driver development, and will probably end up with some kind of licensing agreement for developers that want to write drivers. Until then, the preceding reasons should be adequate justification for NOT attempting a Macintosh printer driver at this time.
If you still aren’t convinced, and want to write a driver despite the challenge, see the article in the December ’88 issue of MacTutor magazine. There is an example printer driver written in C. It is just a skeleton driver, and does not handle any of the more difficult problems such as line layout, font substitution, graphics, or banding. But it is a start, and gives you a general idea of the structure of a driver. Since some developers began writing their drivers before Apple discontinued support, DTS is still answering questions concerning driver development. However, these questions are limited to those that can be answered by the DTS engineers. You should also be aware that some of the techniques used by Apple printer drivers are considered proprietary. Information on methods used for line layout as well as certain aspects of font handling will not be disclosed.
X-Ref:
Printing Manager
Changing printer driver settings without using the dialog
Date Written: 11/6/91
Last reviewed: 6/14/93
To change default printer driver settings without using the dialog, keep a copy of the print record with the various settings you want, and when you want to choose your settings, just use your special print record. The current Macintosh print architecture doesn’t allow procedural access to the print record, so you must call the dialogs once for yourself, choose your settings, and then save a copy of the print record that is produced. Some settings are job-dependent, but values that are retrieved from the print record can be changed using this technique. You can only save the settings in the Style dialog. Call PrValidate when retrieving a print record from the resource fork to make sure it is “good.”
See develop, issue #1, pages 58–65, for a complete discussion of changing default printer driver settings and sample code.
Macintosh print record wDev field
Date Written: 5/3/89
Last reviewed: 8/1/92
What is the Macintosh print record wDev value for the ImageWriter LQ, LaserWriter IISC, and AppleFax Modem?
___
Apple strongly discourages the use of the wDev field in the print record for several reasons. First, this field contains a unique ID for each printer driver on the Macintosh. Coding your application to use this ID makes it device dependent, and device dependence will cause many problems in the future as the Macintosh Printing Manager continues to evolve. Many applications currently check for wDev = 3 to determine whether or not to send PostScript. Although the Apple LaserWriter driver has a wDev of 3, third-party printer drivers for PostScript devices do not, so if your application determines whether or not to send PostScript based on wDev alone, your application may incorrectly print with QuickDraw on third-party PostScript devices. A second problem concerns spoolers and spool files. If a spooler is installed between an application and the printer driver that is going to do the printing, the application receives the wDev ID of the spooler instead of the target driver. If the application makes assumptions based on this ID, it probably gets unexpected results. In the future, it may also be possible to redirect spool files. This means that a file that was originally spooled for a PostScript printer may be redirected to a QuickDraw device. If the spool file contains only the PostScript representation of the document, it will be useless to the QuickDraw device. Despite these strong warnings, some developers are convinced they need the wDev values, and there may be some vertical applications where they’re needed. For those cases, here is the current list of wDev IDs for Apple printer drivers:
Device wDev (Hi Byte)
ImageWriter I/II: 1
LaserWriter,
LaserWriter Plus,
LaserWriter IINT,
LaserWriter IINTX: 3
LaserWriter IISC: 4
ImageWriter LQ: 5
AppleFax Modem: 10
DTS does not support the use of these constants. They are definitely subject to change.
Determining if a printer driver accepts Color QuickDraw calls
Date Written: 11/21/90
Last reviewed: 8/1/92
How do you find out if a printer driver accepts Macintosh Color QuickDraw calls?
___
Check to see if the printer driver has returned a color grafPort to your application after the call to PrOpenDoc (that is, the port that PrOpenDoc returns).
To determine if the grafPort is color, you need to check to see if rowBytes from the grafPort are less than 0. The following code fragment demonstrates this idea:
(* This function determines if the port passed to it is a color port. If *)
(* so, it returns TRUE. *)
FUNCTION ColorPort(portInQuestion: GrafPtr): BOOLEAN;
BEGIN
IF portInQuestion^.portBits.rowBytes < 0 THEN
ColorPort := TRUE
ELSE
ColorPort := FALSE;
END;
Printing in mixed Macintosh System 6/7 network
Date Written: 12/11/90
Last reviewed: 8/1/92
What is the recommended printer driver for a network environment with mixed operating systems (such as System 6.0.5 on a Macintosh Plus and 7.0 on two Macintosh IIfx systems)?
___
In a mixed 6.0.x/7.0 network we recommend upgrading all systems to the 7.0 print drivers—even systems running 6.0.x. The 7.0 LaserWriter drivers work fine under system 6.0.x and will avoid any printer reinitialization problems. Use the 7.0 printing disk (or the printing install folder), and launch the Installer from that disk. It has scripts needed to install 7.0 print drivers on a 6.0.x system. Do not select the Installer options for printers from the main 7.0 Installer, because these scripts currently are only for systems running 7.0.
If a Personal LaserWriter NTR is used on the network, you must upgrade all workstations to the 7.1.1 LaserWriter driver or later. (The NTR requires at least LaserWriter 7.1.1.)
System 7.0 LaserWriter driver & choosing nonstandard page sizes
Date Written: 4/8/91
Last reviewed: 6/14/93
With the System 7.0 version of the LaserWriter driver, when the user selects Envelope from the Page Setup dialog, the page size returned by the driver is still a standard page: 8.5 x 11. How do you recommend that applications display the page size when the user has chosen a nonstandard page size?
___
We recommend that you have the page preview show a full page instead of an envelope-sized page. The LaserWriter driver supports a large number of PostScript devices, and it can’t be sure whether the envelope will be fed on the right, left, or center of the paper tray. If you show the full page, a user can print on any device by putting the text in the correct location for that device.
Manufacturers of PostScript printers can add custom page sizes to the LaserWriter driver. If they do, the representation on the screen will be whatever they decide to define. Applications should not try to interpret custom page sizes. If your application ignores the results returned by the driver, you risk incompatibility down the road.
Asynchronous LaserWriter driver no longer supported
Date Written: 9/24/91
Last reviewed: 8/1/92
What is causing incorrect characters to be printed on the asynchronous LaserWriter driver we licensed from Apple for use with a non-Apple PostScript-equipped printer?
___
The printing of incorrect characters is probably due to an incompatibility between the async driver and the version of PostScript being used in the printer.
The reason for the incompatibility is that the driver is no longer supported and hasn’t been revised for quite some time. The driver was originally developed outside of Apple, and Apple licensed the driver for its use. The company subsequently went out of business and the driver hasn’t been revved since.
PostScript and Apple’s AppleTalk LaserWriter drivers have been updated and changed quite a bit since then, which is why the characters print correctly when using AppleTalk, but not when printing asynchronously. The old async driver just doesn’t know how to handle the new PostScript versions and therefore prints “garbage” characters.
The SL Laser II driver is no longer supported by Apple, and at this time Apple has no plans to update this driver or write a new one. Since things work correctly with AppleTalk, you should confine usage to AppleTalk when printing PostScript to the LaserWriter. If this is unacceptable, you might check around with different clearinghouses to see if a third-party developer has a compatible, up-to-date asynchronous LaserWriter driver that you can use.
Use LaserWriter driver srcCopy instead of srcOr transfer mode
Date Written: 5/1/91
Last reviewed: 6/14/93
I’m creating PICTs that are comprised of many lines drawn in srcOr mode. When using the LaserWriter 6.x or 7.x driver with the Color/Grayscale radio button selected, some lines fail to print. Why is this happening?
___
The problem is a bug in the LaserWriter driver. Sometimes, when using a CGrafPort, the driver doesn’t reproduce lines drawn in srcOr mode. (A CGrafPort is used when the Color/Grayscale print option is selected; in Black & White print mode, a regular grafPort is used.) A workaround is to use srcCopy instead of srcOr when drawing QuickDraw objects within your PICTs.
Save and restore long word if using $948 under System 7
Date Written: 6/11/91
Last reviewed: 8/1/92
Unless my Macintosh application restores the contents of the long word at $948 after using that space for globals, the Finder draws icons incorrectly and my third-party LaserWriter driver crashes. Is somebody now using $948 for other purposes?
___
This is a known System 7 icon drawing bug, and also a bug with the printer driver that you are using.
The icon drawing utilities are trying to determine if a print page is currently open, by looking at that variable ($948 is part of printvars). This turns out not to be such a good idea, and it will be fixed in the next release of the system software.
The printer driver bug that you are experiencing is that every printer driver must return the variable at $948 to -1 when they are done printing. Also, while printing, the driver should set it to <> -1.
Update Backgrounder if using LaserWriter 7.0 under System 6
Date Written: 7/10/91
Last reviewed: 8/1/92
When we use the LaserWriter driver 7.0 with System 6.0, the Chooser’s Background Printing On button is always dimmed. Is there any way to enable background printing?
___
To get the LaserWriter 7.0 driver to work with System 6.0.x, update your Backgrounder file with the version on the Printing Tools disk that’s used to install System 7.0.
In short, to use the 7.0 LaserWriter Driver, 7.0 PrintMonitor, and System 6.0.x, place these files from the System 7.0 Printing Tools installation disks into your System Folder. All three must be used together for printing to work correctly. After you’ve placed these files in the System Folder, you should find the Background Printing option enabled for your use.
There are no known incompatibilities with the 7.0 drivers and System 6.0.x, so everyone should use the latest drivers, even with a mixed environment. This will also get rid of “printer wars” that occur when users use more than one version of the LaserWriter driver to print to the same printer. (The printer must be reinitialized if the current user uses a different version of the driver than that used by the previous user.)
LaserPrep 7.0 file & AppleShare Print Server
Date Written: 7/15/91
Last reviewed: 8/1/92
The LaserPrep 7.0 file is included on the System 7 Printing disk and the System 7 Group Update CD for upgrading the AppleShare Print Server to support the LaserWriter 7.0 driver. The AppleShare Print Server has its own LaserWriter driver built in and all it needs to print is a LaserPrep file. In fact, the AppleShare Print Server completely ignores any LaserWriter driver installed in the System Folder of the server.
Page 49 of the System 7 Group Upgrade Guide states the following procedure for upgrading an AppleShare Print Server to support the System 7 LaserWriter drivers:
1. Shut down the print server software.
2. Install the printer driver update…
3. Drag the LaserPrep icon from the Printer Update folder to the Server Folder of the print server Macintosh.
4. Restart the print server Macintosh and the AppleShare Print Server software.
Actually, step #2 in the System 7 Group Upgrade Guide is unnecessary. Installing the printer driver update has no effect on the AppleShare Print Server software.
LaserWriter 7.0 driver and LaserPrep dictionary
Date Written: 8/29/91
Last reviewed: 6/14/93
In the old LaserWriter drivers it was possible to create a PostScript file with or without the LaserPrep dictionary (“f” or “k” key). Is it possible to generate a file without the dictionary with the LaserWriter 7.0 driver?
___
In 7.0 printing, a LaserPrep dictionary is always sent with a print job. This is done to prevent constant reinitialization of the LaserWriter by conflicting printer drivers. You cannot prevent it from being sent. Fortunately the 7.0 version of the LaserPrep dictionary is much smaller (≈40K total) than its 6.x predecessors.
LaserWriter ignores ForeColor while filling smoothed polygon
Date Written: 10/8/91
Last reviewed: 8/1/92
When doing the FillRgn for drawing the fill of a smoothed polygon (as described in Macintosh Tech Note #91) the foreColor isn’t used on the LaserWriter. Any way to make it work?
___
You’ve discovered a design limitation of the LaserWriter driver. Things that have patterns associated with them are rendered by using the LaserWriter screen operators. This results in an assumption of the foreground color being black and the background color being white, which is what’s causing the problem you noticed. In short, it makes the driver ignore your foreground and background colors.
You can work around the problem by working in an off-screen GWorld first and then CopyBitsing everything to the printer port using srcCopy. There are a couple of problems with this approach: First, don’t do it with text or your text will be turned into a bitmap and you’ll get the “jaggies.” Second, you’ll probably want to increase the printer port’s resolution from its default of 72 dpi for better results. A value of 288 dpi works nicely since it’s an even multiple of QuickDraw’s native 72-dpi resolution. Also, make sure that the GWorld you create has the same bounds as the printer port’s rPage rectangle to avoid unnecessary scaling and clipping. After you’ve done all that, draw into it and CopyBits the result to the printer port. The nice thing about doing everything off-screen first is that then you can use some of the non-printer-friendly transfer modes like blend or dithered. Also, you can use ForeColor/BackColor and get the right thing this way.
If you don’t want to use this method for all printers, (since it can be quite a memory hog), you can check for the LaserWriter driver and use this method in just that case. For other drivers, you should just print as normal.
So, what do you need to do all this? Well, to set the resolution of the printer port, use PrGeneral as described in Inside Macintosh Volume V and develop #3.
To determine whether you have the LaserWriter driver or not, check the high byte of the wDev field in your print handle. This is described in the Tech Note “Optimizing For The LaserWriter—Techniques.” While this method might break some day, it’s currently the best way to determine which driver you’re using, and Apple will have to let developers know before we break it.
If the high byte of the wDev is 3, then you either have the LaserWriter driver or a third-party driver impersonating the LaserWriter. Some PostScript drivers do that because many apps assume a wDev of 3 means a PostScript printer, and anything else doesn’t. By acting like Apple’s LaserWriter driver, they get preferential treatment from apps that “special case” for PostScript. That’s not really a problem in this situation.
I discovered an interesting bug in the Macintosh LaserWriter driver. If the word “timeout” is in the name of a document, the LaserWriter driver will give a timeout error -8132. Are there similar magic words?
___
PostScript error messages are sent from the LaserWriter to the driver as text streams. The driver must check these strings to see if they contain an error message. If a document is named something that contains the same string as a PostScript error message, the driver may think there’s an error when the printer sends the “status: printing document XXXXX” message. Other strings cause similar problems; one of them is “printer out of paper.” If you want to see the rest of the strings, take a look at the LaserWriter printer driver resource type 'PREC' ID = 109.
Personal LaserWriter NTR has longer product string
Date Written: 3/17/92
Last reviewed: 6/14/93
The following line of my PostScript code causes the Personal LaserWriter NTR to gag, but it has worked with all other Apple LaserWriter printers up to now:
statusdict/product get str cvs show % Gets & prints the name of the printer
where str is defined as:
/str 20 string def
___
The product name stored for this printer is (LaserWriter Personal NTR) or (Personal LaserWriter NTR), depending on whether you’re using statusdict or systemdict, respectively. In either case, the product’s length is 24 characters. Since you’re only allocating 20 characters for the 2nd string you use with cvs, you’re getting a rangecheck error. Changing str to:
/str 24 string def
fixes the problem. You may want to make the string even larger than 24 characters to accommodate longer product names in the future.
Assumptions about the length of PostScript product strings are a common problem with new printers (having more verbose names). In fact, you should have the same trouble if you run your original PostScript on the Personal LaserWriter NT, which has a 23 character name.
LaserWriter II SC fonts and 4x bitmap size
Date Written: 11/17/89
Last reviewed: 6/14/93
Why do I need to have four times the bitmap size of the font I want to print in on the LaserWriter II SC?
___
LaserWriter II SC fonts are four times the point size of the associated Macintosh screen font. The pixels on the screen are four times as far apart (center to center) as the dots printed by the LaserWriter SC. When the bitmaps for one of the printer fonts is printed, the result is a font with a resolution four times greater than that of the font displayed, but at a size identical to the font displayed on the screen.
Font families shipped with LaserWriters
Date Written: 11/17/89
Last reviewed: 8/1/92
What fonts and sizes are shipped with the LaserWriter Plus, LaserWriter IInt, LaserWriter IIntx, and LaserWriter SC?
___
The LaserWriter Plus, LaserWriter IInt, and LaserWriter IIntx, shipped with a total of 11 font families with the sizes indicated below:
ITC Zapf Dingbats, New Century Schoolbook 10, 12, 14, 18, 24
A total of four font families are shipped with the SC: Courier, Symbol, Times, and Helvetica in the following sizes: 9, 10, 12, 14, 18, 24, 36, 48, 56, 72,
96.
Disable Graphics Smoothing for printing large bitmap images
Date Written: 5/3/89
Last reviewed: 6/14/93
When printing large (possibly scanned) Macintosh bitmap images, the page is printed with small lines running horizontally through the image. Why?
___
In System 6.0 the QuickDraw DrawPicture call was revised to fix some problems. One of these problems concerned large bitmaps. To help solve the problem of bitmaps that were too large to be printed, DrawPicture was modified to “band” the CopyBits request if it was too large. Banding is the process of converting a large bitmap into several smaller bitmaps. This banding usually occurs vertically down the page. When DrawPicture bands a large bitmap into pieces, the smoothing algorithm of the LaserWriter is applied to each piece separately, instead of being applied to the entire bitmap at once. Since the process of smoothing involves removing some pixels, hairlines will be created between the bitmap bands. There is no way to tell the LaserWriter driver that the smaller bitmaps are all part of one large bitmap, so the only solution to this problem is to disable Graphics Smoothing when printing large bitmap images.
Difference between LaserWriter 7.0 and 7.1 Namer
Date Written: 3/3/92
Last reviewed: 8/1/92
Apple Software Licensing’s “Exhibit C” lists localized Namer 7.0 versions in several languages, and mentions that these localized versions of the Namer are available in version 7.1. What is the difference in the Namer between 7.0 and 7.1?
___
The main difference between the LaserWriter utility 7.0 and 7.1 is that part of the Namer has been integrated into the 7.1 version of the software. Until the LaserWriter utility 7.1 was made available, the Namer was a stand-alone application. However, the LaserWriter utility does not do everything the Namer does. For example, the Namer renames AppleTalked ImageWriters, but the LaserWriter utility doesn’t. For all your printer configuration needs, you should use the 7.1 version of the software.
ImageWriter and printing multiple copies in draft mode
Date Written: 1/6/92
Last reviewed: 6/14/93
Our application can’t print multiple copies on the ImageWriter in Draft mode. If we type in 3 copies in the ImageWriter driver dialog box in Draft mode, we only get one copy. Everything prints fine in Best or Faster modes. Is this a bug in the ImageWriter driver?
___
Although it seems like this must be a bug in the ImageWriter driver, it’s not. In Draft mode, the application that’s printing must make sure the required number of pages are printed. This involves cycling through the app’s print loop for each copy to be printed.
In Draft mode on an ImageWriter, nothing is spooled to disk; the data is immediately sent to the printer. Therefore, the data is no longer available once it’s sent to the printer (and there’s no way for the print driver to resend it for multiple copies). When the ImageWriter spool-prints, the file that’s created is printed the required number of times for you. Therefore, your app only needs to handle multiple copies when printing in Draft mode.
Here’s what your app should do:
1. Validate the print record and present the job dialog. This allows the user to choose how many copies to print and allows the printer driver to adjust the print record to reflect how many copies your program has to print.
2. Get the number of copies that you’re expected to handle from the print record. In the case of spool printing, this number will be set to 1 (since the multiple copies are handled for you by the printer driver). In any case, the following Pascal code will give you the correct info.
numCopies:= printHdl^^.prJob.iCopies; (* From IM 2, pg. 151. *)
3. For each copy in numCopies, loop through the PrOpenDoc/PrCloseDoc section of your code.
This method is demonstrated in the code for the Macintosh Tech Note “A Printing Loop that Cares…,” which describes a model print loop.
Dogcow logo is trademarked
Date Written: 9/10/92
Last reviewed: 6/14/93
We would like to use the “dogcow” icon in our Page Setup dialog. Is the dogcow trademarked, and are there any restrictions on using this icon in our software?
___
Yes, the dogcow logo (along with its call, “Moof!”) is a trademark of Apple and is proprietary. The dogcow appears on Apple’s Developer CD Series disc and in other material. Apple has a pending U.S. registration on it. Accordingly, it’s not available to third-party developers as an icon or file symbol.
“Printer driver is MultiFinder compatible” bit
Date Written: 7/29/92
Last reviewed: 6/14/93
Could you tell me what the “printer driver is MultiFinder compatible” bit is used for?
___
The “printer driver is MultiFinder compatible” bit provides two features. First, it allows the printer driver resource file to be opened by multiple clients. This was obviously needed to support multiple applications printing simultaneously under MultiFinder. The other feature provided by the flag is the loading of PDEFs into the system heap rather than the application heap (which is where they go under the Finder).
The MultiFinder-compatible bit has a major limitation: If your driver has this flag set, you aren’t allowed to add or resize resources, or do anything else that would cause the RAM-resident resource map to change. Although MultiFinder lets multiple applications open the printer resource file at the same time, it has no control over the resource map that gets loaded by the Resource Manager when the file is opened. Because of this, each client gets its own personal copy of the resource map. When these clients get done with the file, they write the resource map back to the file (via UpdateResFile). Obviously, if the resources have changed in any way, the last client to call UpdateResFile is the only one whose changes will be recorded. This is a “thrill seeker” method of handling the printer driver resource files, but since none of the Apple printer drivers currently add or resize resources, it made sense.
So the bottom line here is that if you want your drivers to be compatible under MultiFinder, you’ll have to implement a scheme that doesn’t require adding or resizing resources. It’s OK to change the data in a resource, as long as you don’t change its size. Changing the data won’t cause changes to the resource map, so each client will still have accurate copies of the map.
Here’s what would happen to your printer driver’s resources under the Finder and MultiFinder when the MultiFinder-compatible bit is set:
• Under the Finder in system software version 6.0.x: All resources are loaded into the application heap—regardless of the resource attribute’s bit setting. If the resource has the “load into the system heap” bit set, it will still be loaded into the application heap under the Finder. This makes sense in the Finder world because the application heap will usually have more room than the system heap.
• Under MultiFinder in System 6 or System 7: All the printer driver’s resources will be loaded into the system heap. This is true whether the “load into the system heap” bit is set or not.
Why does the resource loading occur this way, even when the resource’s “load into the system heap” bit is set? Patches to the GetResource trap load all your printer driver’s resources into the system heap when the MultiFinder-compatible bit is set under MultiFinder, and into the application heap under the Finder (as described above), which is why you can’t override this behavior.
By the way, you should be aware of the SetPDiMC MPW tool, which is available on the Developer CD Series disc. It will automatically set the MultiFinder-compatible bit for you when you build your printer driver.
Use FillCRect off-screen, not directly to printer port
Date Written: 8/25/92
Last reviewed: 11/30/92
We’re having problems with color patterns using the LaserWriter driver version 7.1.2. If we create a 'ppat' resource in ResEdit (32 x 32 bits, in this case) and then do a FillCRect to the port returned by PrOpenDoc (with color set so that it’s a cGrafPort) with the pattern loaded by GetPixPat, we get a weird pattern. Doing the same to an off-screen GWorld and using CopyBits to copy to the printer port works fine, if a little slowly. Are we missing something here?
___
You need to use the FillCRect call off-screen rather than directly into the printer port, for at least two reasons. First, the LaserWriter driver doesn’t support filling objects with anything but black-and-white patterns because it uses the PostScript halftone screen functions to draw patterns. Second, the LaserWriter driver doesn’t understand (or handle) pixPats. Therefore, your only recourse is the one you discovered—to copy to and from GWorlds. Unfortunately, FillCRect doesn’t work with the LaserWriter drivers through version 7.2. After version 7.2 this probably won’t be a problem.
Color/Grayscale button on a non–Color QuickDraw Macintosh
Date Written: 8/31/92
Last reviewed: 6/14/93
The LaserWriter driver displays the Color/Grayscale option even on a non–Color QuickDraw Macintosh, which seems odd because the option normally causes the driver to return a CGrafPort to the calling application, and CGrafPorts are only available under Color QuickDraw. What happens if you’re printing original QuickDraw colors using the LaserWriter driver on a non–Color QuickDraw system? Does the driver just use the Black & White code regardless of whether the Color/Grayscale button is selected?
___
Regardless of whether Color/Grayscale is selected or not, the driver returns a grafPort because it’s not running on a Color QuickDraw machine. But, if the Color/Grayscale option is chosen on a Macintosh without Color QuickDraw, the driver doesn’t just use the Black & White code to print. Instead, it sends the colors to the printer as best it can without Color QuickDraw. This can result in three different sets of output when printing classic QuickDraw colors:
• Black & White button selected (identical output whether the system has Color QuickDraw or not)
• Color/Grayscale button selected on Color QuickDraw Macintosh
• Color/Grayscale button selected on non-Color QuickDraw Macintosh
PR 515 - Printing Manager Q&As
Printing
Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As in this Technical Note:
OK to call WaitNextEvent if modal window is frontmost
OK to call WaitNextEvent if modal window is frontmost
Date Written: 1/20/93
Last reviewed: 6/14/93
I’ve read in “Print Hints: Top 10 Printing Crimes” that a program shouldn’t call WaitNextEvent while the Print Manager is open, but I call WaitNextEvent in my pIdleProc so my application can detect a user cancellation. Could this cause a problem?
___
The reason you shouldn’t call WaitNextEvent is to prevent the system from switching to another application. If you have a modal dialog-type window in front (the one with the modal window proc ID), the system will never switch applications and it’s safe to call WaitNextEvent. This is why all Apple’s drivers that call WaitNextEvent put up a modal dialog box. If you have a modal status window frontmost when your pIdle procedure is called, you’re in no danger.
Macintosh Printing Manager error -8132
Date Written: 1/1/90
Last reviewed: 6/14/93
What is Macintosh Printing Manager error -8132?
___
Error -8132 is generated when the selected printer times out. AppleTalk printers monitor the time between data packets that are sent to them. These devices will wait a maximum of two minutes without data until generating a time-out error. Applications such as database report generators sometimes require longer than two minutes to sort or format their data. These applications may receive the -8132 error. One workaround for this problem is to spool the report to a file that can be printed when sorting/formatting is completed.
Another possible solution is to change the amount of time the LaserWriter waits for data until it times out. Keep in mind that the time-out in the LaserWriter exists for a reason. Say a user starts printing a large document and leaves for the day. About halfway through the document, the user’s Macintosh crashes, leaving the printer waiting without data. In two minutes, the LaserWriter times out, and is once again available for other users on the net. However if the time-out is disabled by the first user’s job, the printer is useless until rebooted. To avoid disabling the time-out, increase the time-out value so that the device times-out if the job takes too long to print, but does not time-out for normal delays. This is done by sending the following Postscript to the LaserWriter with a Postscript downloading utility:
serverdict begin 0 exitserver
statusdict begin 0 0 0 setdefaulttimeouts
See the Apple’s LaserWriter Reference for more information.
The only other way to handle this problem is to periodically send some data to the printer. Do this about once a minute or so to prevent the printer from timing out. Use the PostScriptHandle PicComment to send this “tickle” data so that it is only sent to PostScript printers that have the ability to time-out. (Quickdraw printers won’t see the data.) Another reason for using the PostScriptHandle PicComment involves the internal buffering of the LaserWriter driver. The LaserWriter driver maintains a 4K internal buffer for the PostScript that it sends. If you send just a few characters as your tickle data, they are buffered in the driver, and the device still times-out. The only way to ensure that your tickle data makes it to the device is to send a 4K block via the PostScriptHandle PicComment. Needless to say, sending 4K blocks over AppleTalk once a minute is going to cause some network traffic, but it’s still another possible workaround.
Macintosh Printing Manager error -8133
Date Written: 1/1/90
Last reviewed: 8/1/92
What is Macintosh Printing Manager error -8133?
___
Printing Manager error -8133 occurs when the PostScript interpreter of the LaserWriter (or any other PostScript printer) generates a PostScript error. A description of the PostScript command that caused the error is displayed in the status window. This error often occurs when an application sends PostScript directly to the printer, and that PostScript contains an error. To debug this problem, look at the PostScript generated by the driver. Hold down the Command-F key right after clicking okay in the Print dialog. A file named PostScript0 will be created in the current directory. With the 7.x LaserWriter drivers, just select the PostScript File radio button in the Print dialog.
Identifying Macintosh’s currently selected printer
Date Written: 1/1/90
Last reviewed: 8/1/92
How can I find out which printer the user has selected with the Macintosh Chooser? How can I change it without going through the Chooser?
___
The type of the currently selected printer is stored in the System file in 'STR ' resource ID -8192. This will be the name of the driver selected, such as LaserWriter or ImageWriter. The name of the actual printer selected will be in the driver file (same name as the printer type chosen) in 'PAPA' resource ID -8192. Look at this resource with ResEdit to see what is in it.
You can change the 'STR ' and 'PAPA' resources, but it may not work now or in the future. DTS does not recommend changing the system file or circumventing the Chooser! The Chooser is a very complicated piece of software, and it has many dependencies. Implementing the chooser within your application would make your application dependent on a particular version of the system software. Like the Chooser, your application would then have to be revised each time a new system is released.
How to save Macintosh Page Setup and Print dialog options
Date Written: 5/3/89
Last reviewed: 6/14/93
How do I save options set in the Macintosh Page Setup and Print dialogs?
___
The only supported method to save the dialog options is to save the Print Record that was passed to the PrStlDialog/PrJobDialog calls. This print record contains the options chosen in the Page Setup and Print dialogs. Although these options are saved in the print record, they cannot be used as defaults for the Print dialog. For example, say the user chooses landscape printing in the Page Setup dialog, and sets the number of copies to 5 in the Print dialog. If the print record is passed to PrStlDialog, the dialog shows that landscape printing was selected in the print record. However, if that print record is passed to PrJobDialog, number of copies is shown as 1, because options in the PrJobDialog are considered to be “job dependent,” as opposed to “document dependent.”
The best method for saving the print record is to save it as a resource in your document’s resource fork. Since the print record is already pointed to by a valid handle, creating a resource is easy. Here are the required steps:
1. Save the refNum returned by CurResFile;
2. Make sure the resource fork of the document file is opened using OpenResFile (IM I:115).
3. Now that you have a place to put the resource, you must get the resource manager to create it for you. First, pick a type and ID for your resource. You can use the Unique ID function (IM I:121) to generate the ID. Next, call the AddResource procedure (IM I:124). This procedure takes four parameters:
Parameter Type What to Pass
--------------------------
theData Handle The handle to the currently valid print record.
theType ResType The four character resource type you have chosen.
theID INTEGER The ID returned from the UniqueID function.
name Str255 The name for this resource or '' if none.
4. Call WriteResource (IM I:125), and UpdateResFile (IM I:125) to make sure the new resource gets saved into the file.
5. Reset the currently selected file back to whatever it was before you began the save using UseResFile (IM I:117).
The important things to keep in mind when doing this are:
1. Make your resource type something different than those used by the Print Manager. This prevents the Print Manager from getting confused and grabbing the wrong resource. Types to avoid include 'PREC', 'PDEF', and 'POST'.
2. Don’t make any assumptions about the size of the print record. If you really need to know the size, use GetHandleSize.so that if the record gets bigger in the future, your code will still work.
3. Be sure to pass the record that you get from your document to PrValidate before using it. This ensures that the record gets updated if any changes have been made to record structure or contents since the record was saved.
MacApp and SetRsl print driver resolution
Date Written: 4/16/92
Last reviewed: 6/14/93
We’ve been trying to use the standardPrint handler from MacApp 2 to print some views. The problem is that we would like the printout to come out at 300 dpi on the LaserWriter, and the print handler’s device resolution fields (which come from the device driver) tell it to draw at 72 dpi. How, can I get a PenSize(1,1); MoveTo(100,100); LineTo(300,300); draw at 300 dpi and make a nice fine line? Please refer me to the needed documentation.
___
The mechanism by which your application can find out the chosen printer’s real resolution, and then draw with it, is documented “Meet PrGeneral, the Trap That Makes the Most of the Printing Manager,” in issue #3 of develop magazine (July 1990). You can find it, along with its accompanying code and application, on the Developer CD, E.T.O., and AppleLink.
The DTS Sample Code SC.009.FracApp300 on the Developer CD shows how to use PrGeneral in an application built with MacApp 2.
Printing patterns at higher resolutions with GetRslData & SetRsl
Date Written: 11/7/90
Last reviewed: 6/14/93
Is there a way that I can make my Macintosh fill patterns print at a higher resolution (more than 72 dpi), but have my patterns still print as patterns?
___
To make your patterns print at the printer’s resolution, you need to use Printing Manager PrGeneral’s GetRslData and SetRsl opcodes to get and set the resolution, and you must scale the pattern to match. Let me explain.
If we do not scale our patterns up to the printer’s resolution before print time, we would get “big chunky” patterns because the printer driver would need to scale the patterns on the fly from 72 dpi to its resolution. Therefore, we use the “cookie cutter” approach to “place” the pattern into the object that is being filled. The size of the cookie cutter (that is, the destination Rect) depends on the “scaleFactor”. For example, a scaleFactor of 2 will have a destination rect of 16 x 16. We will then CopyBits the pattern one square at a time into the object that is being filled.
XRefs:
Inside Macintosh Volume V, pages 410-416
“Meet PrGeneral,” develop, July 1990
Call Printing Mgr’s bottleneck to send StdText to printer driver
Date Written: 11/7/90
Last reviewed: 6/14/93
We need to use the Macintosh toolbox call StdText instead of DrawChar, DrawString, and DrawText to accomplish horizontal scaling and fractional point sizes, but StdText does not work on the LaserWriter IISC. Is there any workaround?
___
The problem is that you are calling the low-level bottleneck directly, and the Printing Manager has replaced the bottleneck completely with its own. So when you are actually printing, the print driver will not see your call to StdText. The work-around for this is to call the Print Manager’s bottleneck itself when you are printing. You can do this in the following way:
/* typedef the function */
typedef pascal void (*StdTextProcPtr)( short, Ptr, Point, Point );
void tstDrawStuff( pInfo, thePort, pageNum )
TPrint pInfo;
GrafPtr thePort;
unsigned short pageNum;
{
StdTextProcPtr Proc; /* declare a variable here */
/* do your clipping etc. */
/* TEST -- no good w/o PriMon */
/* do your moveto etc. */
/* Is there a replacement bottleneck ?*/
if ( thePort->grafProcs ) {
Proc = (StdTextProcPtr)thePort->grafProcs->textProc; /* yes, so grab it */
This technique will work in both background and foreground printing. I have tested this solution on the Personal LaserWriter SC and the LaserWriter IINTX, and it prints fine.
Modifying PDEFs to have printer driver jump into dialog code
Date Written: 11/9/90
Last reviewed: 6/14/93
Could you please point me to the correct section in “Learning to Drive” (or send me an example) that we would need to modify the appropriate PDEF resource in order to have the driver jump to our dialog code?
___
Pages 15-18 discuss the contents of the various PDEFs. You will need patch the appropriate PDEF to get your required functionality. You should also realize that patching PDEFs is not an easy task, nor will it always survive “new” Macintosh LaserWriter driver releases. I want you to know that before you go too far down the PDEF patching road.
By the way, we do know of a couple of developers that have patched PDEFs successfully. The following paragraphs are a “high-level” look at patching a PDEF:
To patch a PDEF, you must write an installer application that lets users choose the printer driver they want to modify via Standard File. You can cause Standard File to display only printer drivers by telling it to display only files of type “PRER”. Once the user has selected a driver you need to scan the driver for the PDEF 0 and 1 resources. When you find one of these you read it in and modify it.
However, I'll give you a quick overview of what you need to do. PDEF 0 & 1 both start with jump tables (a table of JMP instructions followed by the PC relative address to jump to). The JMP to PrClosePage always begins at offset 12. So what your installer needs to do after it loads the resource is grab the eighth word in the resource. That is the offset to the actual start of the PrClosePage code. Then you have to resize the handle so that it is big enough to hold your patch and then BlockMove {IM II-44} your code into the end of the handle. The following illustration might help:
JMP $0486 << Note: some PDEF's have multiple JMPs at
* - - - - - - - - - - - - - * the beginning of the code. The
* * original offset to PrClosePage was
* >> Original PDEF code << * $0386.
* *
$0386 --> PrClosePage << Note: most PDEF's have multiple printing
* * calls defined.
* *
* - - - - - - - - - - - - - *
$0486 --> {{{ Your Code }}}
* * << You resize the resource handle to this
* * and blockmove your code in here.
* *
* - - - - - - - - - - - - - *
JMP $0386 << At this point we jump into the printer
driver's original code for PrClosePage.
Note: The previous illustration is not to scale nor completely accurate in regards to the addresses used. Please consult “Learning To drive” for the correct offsets for each PDEF.
Then replace the original offset to PrClosePage with the offset to your new code. Remember that this is PC relative so you would calculate it like this: If the original PrClosePage JMP was JMP 10(SP) and the size of the original PDEF was 50 bytes, then you need to replace the JMP 10(SP) with JMP 50-16(SP). In other words, you need to JMP to what was formerly the end of the PDEF resource but what is now the beginning of your code (subtract 16 because the offset table is 16 bytes long. Refer to “Learning to Drive” for more details). Then on the end of your code, add a JMP ((SizeOfJumpTable + originalOffset) – (sizeofOriginalPDEF + SizeOfYourCode))(SP). Your code will end with a JMP to a negative offset off the PC back to the original PrCloseRoutine.
If you are willing to support only system software later than version 3.3 (basically that means that you won’t be supporting Macintosh 512K and 512KE computers), you don’t have to deal with all the PDEF changing, and you can simply patch out the $A8FD trap and look for the proper selector on the stack. (Use SysEnvirons to be sure that you are on a system later than version 3.3) This will work because the newer libraries (that is, any library that shipped since the Macintosh II shipped) first checks for the trap and jumps there if the trap exists so even if the application has linked in the printing library they still end up calling the trap on systems after 3.3.
Determining if printer supports color and/or grayscale printing
Date Written: 3/14/91
Last reviewed: 8/1/92
Is there any way to determine whether I’m printing to either a color printer or a printer simulating color, such as the LaserWriter set for Color/Grayscale?
___
Check the grafPort returned by your call to PrOpenDoc. If the rowBytes of the grafPort is less than 0, the Printing Manager has returned a color grafPort. You can then make Color QuickDraw calls into this grafPort. LaserWriter driver version 6.0 and later returns a color grafPort from the PrOpenDoc call, if the Color/Grayscale button has been set.
The following code fragment demonstrates this:
(* This function determines whether the port passed to it is a *)
(* color port. If so, it returns TRUE. *)
FUNCTION IsColorPort(portInQuestion: GrafPtr): BOOLEAN;
BEGIN
IF portInQuestion^.portBits.rowBytes < 0 THEN
IsColorPort := TRUE
ELSE
IsColorPort := FALSE;
END;
A third-party printer driver should return the type of grafPort that represents the abilities of its printer. Therefore, if the printer supports color and/or grayscale, and if Color QuickDraw is present, the application will receive a color grafPort after calling PrOpenDoc. Otherwise, if the Macintosh you’re running on does not support Color QuickDraw, you should return a black-and-white grafPort.
Using LaserWriter fonts with StyleWriter
Date Written: 3/22/91
Last reviewed: 6/14/93
Can StyleWriter use all the Adobe fonts for my LaserWriter? Can StyleWriter print the encapsulated PostScript drawings I’ve developed? Does TrueType software come with the StyleWriter?
___
The difference between the StyleWriter and a regular LaserWriter (other than one’s got a laser and the other doesn’t) is that the LaserWriter has PostScript built-in; the StyleWriter does not. The StyleWriter, in fact, has nothing built-in, and only recognizes basic “put this dot here” types of commands. Even sending it pure ASCII accomplishes nothing.
TrueType software is shipped with the StyleWriter, because it can image fonts at any resolution with excellent quality, much like PostScript. The TrueType software is intended for users of system versions 6.0.7 and later, but prior to System 7. System 7 includes support for TrueType.
You can use PostScript images and fonts with the StyleWriter, but just as with the ImageWriter, you’ll have to have something that images them in memory before sending them to the printer (in other words, a Macintosh-resident PostScript interpreter).
Personal LaserWriter LS 1.1 driver is faster
Date Written: 8/9/91
Last reviewed: 6/14/93
My LaserWriter LS is very slow when printing from my Macintosh SE. Any suggestions?
___
Use the new LaserWriter LS driver version 1.1 or later. It was released after System 7.0, and is available on AppleLink or from your dealer.
If you’re printing Word files, Microsoft’s TrueType INIT will help. It’s available from MicroSoft Technical Support or from commercial bulletin board services.
ImageWriter II 6.1 & 7.0 driver PrGeneral/PrStlDialog bug
Date Written: 9/11/91
Last reviewed: 6/14/93
If an application uses PrGeneral to set draftBits mode on an ImageWriter II (using the 6.1 or 7.0 drivers) and then does a PrStlDialog, a fatal crash occurs. This happens with both the AppleTalk and non-AppleTalk drivers. This only happens on Macintosh systems with Color QuickDraw.
The problem is connected to the two 'dctb' resources which were added in the 6.1 driver. When the landscape icon is being grayed out (since it’s unsupported in draftBits mode), the driver is jamming the gray pen pattern directly into the GrafPort. While this brute-force method works fine with GrafPorts, the 'dctb' resources make the Dialog Manager use a CGrafPort now. Jamming the pattern into this CGrafPort as if it were a GrafPort makes a mess and causes a fatal crash, manifesting itself as a “division by zero” error, for example.
To work around the problem, check to see if you are printing to a 6.1 or 7.0 ImageWriter driver, and if so, do the style dialog before setting draftBits. The disadvantage of this is that setting draftBits before calling PrStlDialog causes the 50% reduction and landscape controls to be disabled, and this method doesn’t. Therefore, after the style dialog, you should check to see if the user selected landscape printing or 50% reduction by calling PrGeneral (getRotnOp) and checking bit 3 of the wDev field (See “Learning To Drive” on the Developer CDs for more about the wDev.) If the user selected either of those options, display a dialog warning them that those features will be ignored. Then, call PrGeneral to set draftBits and continue normally. PrGeneral will adjust the print record so that options not supported with draftBits are turned off. If a non 6.1/7.0 ImageWriter driver is used, the code should set draftBits as usual, before the PrStlDialog call.
This workaround is the better alternative to hacking the 'dctb's out of the driver or patching around the problem, although it doesn’t help 7.0 users running applications that already make use of the draftBits option. The following Pascal snippet demonstrates how to use the workaround:
(* Sample snippet that demonstrates how to work-around the
'dctb' bug in the ImageWriter II 6.1 and 7.0 drivers.
Bug causes a crash when doing a style dialog
after setting draftbits with PrGeneral.
*)
{
What's what in the code snippet that follows.
thePrRecHdl : THPrint;
rslData : TSetRslBlk;
draftData : TDftBitsBlk;
rotnData : TGetRotnBlk;
isBadImageWriter : Boolean;
isLandscape : Boolean;
isReduced : Boolean;
}
PrOpen;
IF (PrError = noErr) THEN
BEGIN
PrintDefault(thePrRecHdl);
IF (PrError = noErr) THEN
BEGIN
{See if we're using a version 6.1 or 7.0 ImageWriter driver.}
IF (thePrRecHdl^^.prStl.wDev DIV 256) = 1 THEN
isBadImageWriter := (PrDrvrVers = 61) OR (PrDrvrVers = 70)
ELSE
isBadImageWriter := FALSE;
IF NOT (isBadImageWriter) THEN
BEGIN
{Set draftBits mode now, if not our special case.}
draftData.iOpCode := draftBitsOp;
draftData.hPrint := thePrRecHdl;
PrGeneral(@draftData);
END;
{Do the style dialog.}
IF (PrStlDialog(thePrRecHdl)) THEN
IF (isBadImageWriter) THEN
BEGIN
{If so, see if they selected rotation or 50% reduction.}
rotnData.iOpCode := getRotnOp;
rotnData.hPrint := thePrRecHdl;
PrGeneral(@rotnData);
isLandscape := rotnData.fLandscape;
isReduced := BTst(thePrRecHdl^^.prStl.wDev, 3);
{If so, warn them that those things will be ignored.
{Now, set draftBits mode, since we didn't before.}
draftData.iOpCode := draftBitsOp;
draftData.hPrint := thePrRecHdl;
PrGeneral(@draftData);
END;
IF (PrJobDialog(thePrRecHdl)) THEN
BEGIN
{Print}
END;
END;
END;
PrClose;
How to abort printing while PrPicFile is executing
Date Written: 9/27/91
Last reviewed: 6/14/93
Can I abort printing from within PrPicFile? My attempts haven’t been succesful.
___
The following Pascal procedure is roughly the same as the default idle procedure—the one the system supplies for you when you don’t supply one of your own:
procedure MyPIdleProcedure;
var
pIdleEventRecord: EventRecord;
begin
if GetNextEvent(keyDownMask, pIdleEventRecord) then
begin
if ((BitAnd(pIdleEventRecord.message, charCodeMask) =
(This is written in Think Pascal, but it should work fine under MPW Pascal if you change the “BitAnd” functions to “BAND”.)
As you can see, the system aborts when you press Command-period by using PrSetError to the constant iPrAbort, which is the same error returned when the user clicks “Cancel” in the style or job dialogs. If you set the error to iPrAbort, the system will take care of the rest. Your print loop will also gracefully cancel, provided you follow the guidelines in the Macintosh Technical Note “A Printing Loop That Cares.”
Disabling ImageWriter’s initial formfeed
Date Written: 1/23/92
Last reviewed: 6/14/93
When our product-to-be prints to the ImageWriter II there is an automatic (and undesirable in our product) sheet feed before actual printing begins. To make matters worse, it always feeds 11", even though our form is a different length. Is there a way to avoid this?
___
The ImageWriter ejects a page before printing with the “No Gaps” option selected because it assumes that the page is aligned with a small gap between the perforation and the print head. So the printer ejects the page and re-aligns the print head at the perforation of the next page.
The sample code below illustrates how to prevent that nasty form feed from occurring. The program temporarily disables the “No Gaps” option if it is selected until after PrOpenDoc is called, preventing a formfeed from occurring. After PrOpenDoc is called, the program re-enables the “No Gaps” option.
Please note that this sample only works with the ImageWriter II and the ImageWriter LQ printers—probably the only series that supports the “No Gaps” option. The sample shows how to check for these types of printers, so you shouldn’t have any problems.
{ Draw whatever you want here. Make sure it fits in the world rectangle. }
BEGIN
MoveTo(100, 100);
DrawString('testing...');
END;
FUNCTION HiByte(word: INTEGER): Byte;
BEGIN
HiByte := word DIV 256;
END;
PROCEDURE PrintStuff;
VAR
thePrRec: THPrint;
thePrPort: TPPrPort;
theStatus: TPrStatus;
oldPort: GrafPtr;
theError: OSErr;
theVers: INTEGER;
NoGaps: BOOLEAN;
BEGIN
GetPort(oldPort);
thePrRec := THPrint(NewHandle(SIZEOF(TPrint)));
PrOpen;
IF PrError = noErr THEN BEGIN
PrintDefault(thePrRec);
IF NOT PrStlDialog(thePrRec) THEN
PrSetError(iPrAbort);
IF NOT PrJobDialog(thePrRec) THEN
PrSetError(iPrAbort);
(* First, lock the handle down so we can do a cool with statement. *)
HLock(Handle(thePrRec));
IF PrError = noErr THEN
WITH thePrRec^^ DO BEGIN
(* Okay, now get device dependent. We only want to do this if we *)
(* know the selected printer driver supports it. *)
IF (HiByte(prStl.wDev) = bDevImageWriter) OR
(HiByte(prStl.wDev) = bDevImageWriterLQ) THEN BEGIN
(* Now remember the state of the nogaps option. *)
NoGaps := BitTst(@prStl.wDev, 11);
(* If NoGaps was selected, then turn it off until we PrOpenDoc.*)
IF (NoGaps) THEN BitClr(@prStl.wDev, 11);
(* If we're on the LQ driver, we need to copy the wDev into the*)
(* PrintX array, or the LQ driver won't notice that it changed.*)
IF (HiByte(prStl.wDev) = bDevImageWriterLQ) THEN
PrintX[2] := prStl.wDev;
END;
END;
HUnlock(Handle(thePrRec));
(* Now open the document. *)
thePrPort := PrOpenDoc(thePrRec, NIL, NIL);
(* Now we need to see if the NoGaps option was selected. If it was *)
(* then we turned it off before calling PrOpenDoc, so we need to *)
(* turn it back on. If wasn't selected, we won't do anything. *)
HLock(Handle(thePrRec));
WITH thePrRec^^ DO BEGIN
IF NoGaps AND
(HiByte(prStl.wDev) = bDevImageWriter) OR
(HiByte(prStl.wDev) = bDevImageWriterLQ) THEN BEGIN
(* Turn it on for the ImageWriter. *)
BitSet(@prStl.wDev, 11);
(* Copy it over for the ImageWriter LQ. *)
IF (HiByte(prStl.wDev) = bDevImageWriterLQ) THEN
PrintX[2] := prStl.wDev;
END;
END;
HUnlock(Handle(thePrRec));
IF PrError = noErr THEN BEGIN
PrOpenPage(thePrPort, NIL);
IF PrError = noErr THEN BEGIN
DrawStuff(thePrRec^^.prInfo.rPage);
END;
PrClosePage(thePrPort);
END;
PrCloseDoc(thePrPort);
IF (thePrRec^^.prJob.bJDocLoop = bSpoolLoop) and (PrError = noErr)
THEN PrPicFile(thePrRec, NIL, NIL, NIL, theStatus);
END;
PrClose;
DisposHandle(Handle(thePrRec));
SetPort(oldPort);
END;
BEGIN
InitGraf(@thePort); {initialize QuickDraw}
InitFonts; {initialize Font Manager}
FlushEvents(everyEvent, 0); {call OS Event Mgr to discard}
{any previous events}
InitWindows; {initialize Window Manager}
InitMenus; {initialize Menu Manager}
TEInit; {initialize TextEdit}
InitDialogs(NIL); {initialize Dialog Manager}
InitCursor; {call QuickDraw to make cursor (pointer) an arrow}
PrintStuff;
END.
Update Macintosh color table if printing in color
Date Written: 5/3/89
Last reviewed: 6/14/93
I’m having trouble printing in color. When I copy a color image from a Macintosh offscreen pixmap to the printer, I get a black piece of paper. If I draw directly it comes out fine. What am I doing wrong?
___
When you built your offscreen port and copied the color table from a GDevice, did you change the color table to reflect that the color table is now part of a pixmap? In a GDevice the color table’s value field is zero for all entries, but in a pixmap the value field represents the index value of each color in the table. If the color table has not been converted, printing won’t work properly.
PR 520 - PrintMonitor Q&As
Printing
Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As in this Technical Note:
Determining whether background printing is enabled
Determining whether background printing is enabled
62755 MD JM dy 1
Date Written: 1/20/93
Last reviewed: 4/26/93
How can I tell whether background printing is enabled for the selected printer?
___
There’s no procedure to determine whether the user has picked background printing because that’s not a standard Macintosh system software feature. Where it’s done, it’s implemented on a driver-by-driver basis, and each printer driver keeps track of it in a different way. Apple does it one way, Hewlett-Packard might do it another way, GCC a third way, and so on.
Since we don’t actually know how it’s done, and since Apple doesn’t guarantee its drivers will do it the same way in the future as they do now, we have no information to give you on how to determine this. Sorry to be the bearer of bad news.
Location for spool files under System 7.0
Date Written: 12/18/90
Last reviewed: 8/1/92
Is there a recommended location for printer driver writers to put their own spool files?
___
Place it in the “PrintMonitor Documents” folder within a “personal spool” folder. PrintMonitor will ignore other folders and it will delete its spool file when it was done with it.
The biggest advantage with this approach is that all the spool files end up in the same location, which is probably the best solution for the native user.
There are a few cases when the folder might not be present (such as if the user has deleted it for some reason). Therefore, you should check to make sure that the folder is present before trying to add a file to it. If it is not present, be sure to create it with the exact name; otherwise, PrintMonitor will not be able to find it and will create a second folder with a different name, possibly confusing the native user. Folder management is relatively straightforward with the addition of the “Folder Manager” to System 7.0. The Finder chapter in Inside Macintosh Volume VI contains the details about using it.
Determining whether background printing is turned on
Date Written: 2/5/92
Last reviewed: 8/1/92
I need to know whether the currently chosen printer driver—that I’m about to print to—is going to be doing background printing or not. The user interface of our application is somewhat different, depending on this. Currently, I check the driver’s file type to see whether it’s network- or local-attached, generalizing “network = LaserWriter = background capable” and “direct = ImageWriter = foreground only,” but I know this isn’t always correct, because a variety of direct-connect printer drivers now support background printing. What I really need is a way to check specifically for background printing being turned on. Is there a safe and driver-independent way to check this?
___
No, there’s absolutely no safe and driver-independent way to do this. Although Apple uses PrintMonitor for all background printing, it’s not designed for third-party products to hook into it. The “background printing” internals aren’t documented because changing that outside an individual printer driver may not give the driver all the information it needs to correctly print in the background. Also, third parties have to implement their own background printing schemes, and there’s absolutely no way to know how they’re storing the choice on whether or not to print in the background.
If your user interface is substantially different, you may need to require your users to enable background printing in your application as well as in the Chooser. This isn’t exactly friendly, but since there’s no mechanism for applications to communicate with printer drivers to find out about background printing, it’s pretty much your only choice.
You’re right, checking a driver’s file type to see whether it’s network- or local-attached is not a good solution. StyleWriters and LaserWriter LS printers print in the background but don’t use a network. Some third-party laser printers support AppleTalk but not background printing.
Turning Macintosh background printing on and off
Date Written: 3/25/92
Last reviewed: 6/14/93
Someone has requested that we do an extension for our application to turn background printing on and off. Can you tell me how to do this?
___
Unfortunately, DTS can’t tell you how to turn background printing on and off, for the following reasons:
1. Apple’s mechanism for background printing (PrintMonitor) is at this time only available to Apple’s printer drivers. How Apple’s printer drivers store the background printing choice is private because Engineering has changed it in the past and might need to change it again.
2. Since all third-party printer drivers that do background printing have to do it their own way, they all have to find their own ways of recording the “background printing” choice, such as storing the information in resources like the PAPA resource. Since there are no guidelines for recording background printing options, DTS cannot recommend a method which will work with all drivers.
For these reasons, and to avoid possible Human Interface conflicts, background printing control is best left to the user.
Macintosh PicComments and background printing
Date Written: 5/3/89
Last reviewed: 6/14/93
My Macintosh application prints fine when Background Printing is disabled, but doesn’t print or prints blank pages when Background Printing is enabled. Why?
___
The Printing Manager gets execution time by replacing the grafProcs of the Printing Manager GrafPort (returned from the PrOpenDoc call). This GrafPort is created by the PrOpenDoc call, and is reinitialized by every call to PrOpenPage. On the LaserWriter driver with Background Printing enabled, this reinitialization causes the clipping region of the port to be set to (0,0,0,0). On the next call to StdLine or StdText, for example, the Printing Manager notices the zeroed clipping region, and sets it to the rectangle specified by prInfo.rPage in the print record. If your application prints its documents with PostScript using PicComments, the Printing Manager never gets a chance to define the clipping region. All of your PostScript code is sent to the LaserWriter and executed, but the results are clipped to (0,0,0,0). To work around this problem, you must call at least one Quickdraw drawing routine at the beginning of each page. The following is frequently used:
PrOpenPage(...);
MoveTo(-32000, -32000);
Line(0, 0);
{ PostScript code here }
PrClosePage(...);
The MoveTo is needed so that the line is drawn outside of the imageable area of the page, and thus is invisible. The Line call calls the Printing Manager’s version of the StdLine procedure, which defines the clipping region for the port. All subsequent PostScript code will be clipped correctly. Since PrOpenPage resets the clipping region, the MoveTo/Line combination must be done after each call to PrOpenPage.
SetOrigin and background printing
Date Written: 1/1/90
Last reviewed: 6/14/93
I have noticed PostScript graphics printing in different locations depending on whether or not Background printing is enabled on the Macintosh. What causes this?
___
In LaserWriter 4.0 - 5.2, SetOrigin is handled differently when Background printing is enabled. The method used by these drivers is described below:
Background Printing DISABLED: The application calls SetOrigin, and QuickDraw responds to the call by adjusting the portRect of the Print Manager’s GrafPort. Since SetOrigin does not cause any grafProcs to run, the Printing Manager doesn’t see this change until the next QuickDraw drawing operation such as DrawString or LineTo. At that time, the Printing Manager notices the change in the portRect, and updates its internal origin. All QuickDraw graphics are now localized to the new origin. All PostScript graphics will also get the localization to the new origin.
Background Printing ENABLED: Because QuickDraw is playing back a picture that was spooled earlier, it handles calls to SetOrigin a little differently. When the SetOrigin call is encountered in a DrawPicture call, the portRect of the GrafPort is NOT updated. Instead, QuickDraw keeps the current origin cached, and offsets each graphic on the fly. Since the portRect was not modified, the Printing Manager does not see the SetOrigin call. Although all QuickDraw objects are still localized correctly (by QuickDraw), PostScript graphics do not move to the new origin. Instead, the application localizes the coordinates of its PostScript graphics. You could also use the technique documented in the Technical Note “Position-Independent PostScript.”
The implementation of the SetOrigin (IM I:166) and ClipRect (IM I:167) calls has been revised in LaserWriter 6.0. This is a general description of those changes:
LaserWriter 6.0: Both QuickDraw and PostScript coordinates are offset with respect to the origin set by SetOrigin. The driver now inserts a picture comment into the spool file so that the Print Monitor knows that the origin was changed during spooling.
Since applications must support versions of the LaserWriter driver other than 6.0, they should still use the method described in this Tech Note to make sure their PostScript is position-independent.
X-Ref:
DTS Macintosh Technical Note “Position-Independent PostScript”
Macintosh spool file formats aren’t available
Date Written: 1/1/90
Last reviewed: 8/1/92
What is file format of Macintosh Printing Manager and LaserShare spool files?
___
Unfortunately, the formats for these files are not currently available, and it is doubtful that they will be made available in the future. Whenever new features are added to LaserShare, the Printing Manager, or other parts of the Macintosh toolbox, it’s not uncommon for these spool file formats to be affected. If the file format were published, and essentially frozen, it would be much harder for engineering to add features.
PR 525 - QuickDraw GX Printing Q&As
Printing
Revised by: Developer Support Center September 1993
Written by: Developer Support Center October 1990
This Technical Note contains a collection of Q&As relating to a specific topic—questions you’ve sent the Developer Support Center (DSC) along with answers from the DSC engineers. While DSC engineers have checked the Q&A content for accuracy, the Q&A Technical Notes don’t have the editing and organization of other Technical Notes. The Q&A function is to get new technical information and updates to you quickly, saving the polish for when the information migrates into reference manuals.
Q&As are now included with Technical Notes to make access to technical updates easier for you. If you have comments or suggestions about Q&A content or distribution, please let us know by sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical questions about Q&A content to DEVSUPPORT for resolution.
New Q&As for this month:
QuickDraw GX printing extensions and creator types
QuickDraw GX printing extensions and creator types
Date Written: 5/3/93
Last reviewed: 7/2/93
A QuickDraw GX printing extension I’ve already written works fine, but when I install my latest creation, it doesn’t show up in the print dialog—only my old printing extension does. Both extensions are the same except for a few lines of code in their gxDespoolPage message overrides. What’s going on?
___
Your printing extensions shouldn’t have the same creator type. QuickDraw GX requires unique creator types for drivers and printing extensions, just as the Finder does for applications. A creator type must be unique because QuickDraw GX uses it to build its chain of message handlers. If two printing extensions have the same creator, there’s no way to determine which is which in the chain. You can register creator types for your printer drivers and printing extensions with the Developer Support Center (AppleLink DEVSUPPORT).
NewMessageGlobals and global data
Date Written: 2/1/93
Last reviewed: 7/2/93
Why can’t I get NewMessageGlobals to work in my gxInitialize message for my QuickDraw GX printing extension? The global data I try to initialize isn’t being accessed correctly.
___
You shouldn’t call NewMessageGlobals from any routine in which you access your global data. Otherwise, because of optimization that your compiler may perform, the data references can be invalid. Instead, use an approach like this:
extern long A5Size(void);
extern void A5Init(void *);
typedef struct GlobalType {
StringHandle aString;
} GlobalType;
GlobalType myGlobals;
/* This routine sets the initial values of our global data. */
OSErr InitGlobalData()
{
OSErr err;
// Initialize our globals.
myGlobals.aString = GetString(r_myStringID);
err = ResError();
if (!err) DetachResource(myGlobals.aString);
return err;
}
/* Our override for the gxInitialize message. */
OSErr MyInitialize()
{
OSErr err;
// Create an A5 world, then go initialize our global data.
err = NewMessageGlobals(A5Size(), A5Init());
if (!err) err = InitGlobalData();
return err;
}
A detailed explanation of the problem accompanies the Kabooms printing extension sample on the Developer CD.
When a QuickDraw GX PostScript printer driver generates a file, will it work for Level 1 and Level 2 printers?
___
The LaserWriter driver bundled with QuickDraw GX produces a flavor of PostScript that we call “portable.” This flavor is meant to work on the widest range of printing devices, be they Level 1 or 2, color or black and white.
QuickDraw GX PostScript Level 2 features used
Date Written: 11/17/92
Last reviewed: 7/2/93
What PostScript Level 2 features does the QuickDraw GX printing mechanism take advantage of?
___
The Level 2 features used in QuickDraw GX mostly have to do with patterns, text, and bitmaps:
• QuickDraw GX patterns are converted into Level 2 pattern dictionaries when going to a Level 2 printer. The actual PostScript code emitted by the driver differs little with respect to patterns when going to Level 1 or Level 2. However, the procedures defined in the header do something entirely different on a Level 2 printer.
• Line layout in QuickDraw GX takes advantage of the xshow, yshow, and xyshow operators when it makes sense to do so.
• The Level 2 rectangle operators are used in Level 2, though this happens in the procedures defined in the header rather than in PostScript code from the driver.
• On Level 2 printers, the indexed color spaces are used for printing bitmaps up to eight bits deep.
• The plan is to use Level 2 device-independent color when possible.
QuickDraw GX printer drivers and color option
Date Written: 9/14/92
Last reviewed: 7/2/93
The LaserWriter driver before the QuickDraw GX version has an option to print in Color/Grayscale or Black & White. Why isn’t this option in the QuickDraw GX LaserWriter driver?
___
The Color/Grayscale option was added to the LaserWriter driver only for compatibility reasons. At the time, some applications couldn’t deal with the color option (specifically with cGrafPorts), so a Black & White mode was also provided. The Black & White mode exhibited the same functionality as the earlier LaserWriter driver 5.2.
Because most applications are color compatible now, the option was removed from the QuickDraw GX printer drivers. Some people reported that the option let them print faster when they chose Black & White. This was true because of quirks in the earlier LaserWriter driver version. Under QuickDraw GX, this shouldn’t be a problem. If it turns out to be a problem for your driver, you could incorporate black-and-white threshold printing into your “rough draft mode” code. The QuickDraw GX LaserWriter driver always prints in color.
T ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å Ì ( õ ZPR 1 - Color Printing
° d ONLN d Ä < è s *Printing
° d ONLN d õ < ß t * Revised by: ° d ONLN d , õ Ñ ß Û )HScott "ZZ" Zimmerman ° d ONLN d A õæ ߲ ( √‹ January 1988 ° d ONLN d Q ß≈ ≥˛ +
March 1988 ° d ONLN d \ ≥ < ø q ( € Z Written by: ° d ONLN d h ≥ Ñ ø – )HGinger Jernigan ° d ONLN d x ≥∏ ø˛ ( €÷
February 1986 ° d ONLN d Ü À < ◊F ( Û Z9This discusses color printing in a Macintosh application. X ° d ONLN d ¿ < ¸ *%\Whereas the original eight-color model of QuickDraw was sufficient for printing in color on ° d ONLN d ¸˛ (the ° d ONLN d ¸ < ë ($ ZImageWriter II, ° d ONLN d0 ¸ ë˛ )UAthe introduction of Color QuickDraw has created the need for more ° d ONLN dr < – (0 Z sophisticated printing methods. ° d ONLN dí <,w *BThe first section describes using the eight-color QuickDraw model ° d ONLN d‘ w,˛ (Hïwith the ImageWriter II and ° d ONLN d, <8n (T Z=ImageWriter LQ drivers. Since the current Print Manager does ° d ONLN d-,n8˛ (Tå not support Color GrafPorts, ° d ONLN dJ8 <Dè (` ZHthe eight-color model is the only method available for the ImageWriters. ° d ONLN dìP <\Ω *NThe next section describes a technique that can be used for printing halftone ° d ONLN d·PΩ\˛ (x€ images using ° d ONLN dÓ\ <h" (Ñ Z2PostScript (when it is available). Also described ° d ONLN d \"h˛ )Ê-is a device independent technique for sending ° d ONLN dNh <t õ (ê Zthe PostScript data. ° d ONLN dch õt˛ )_JThis technique can be used on any LaserWriter driver 3.0 or later. It will ° d ONLN dÆt <ÄW (ú Z;work with all LaserWriters except the the LaserWriter IISC. ° d ONLN dÍå <ò *4It is very likely that better color support will be ° d ONLN d å ò˛ )‡/added to the Print Manager in the future. Until ° d ONLN dNò <§ (¿ Z+then, these are the best methods available.
° d ONLN dzº <À *'Part 1, ImageWriters
° d ONLN dè◊ <„ Í *$The ImageWriter drivers are capable ° d ONLN d≥◊ Í„˛ )Æ:of generating each of the eight standard colors defined in ° d ONLN dÓ„ <Ô ı ( Z%QuickDraw by the following constants: ,
Courier ° d ONLN d˚ ` ¶ +$
whiteColor ° d ONLN d! ` ¶ *
blackColor ° d ONLN d- ` ò * redColor ° d ONLN d7 `+ ¶ *
greenColor ° d ONLN dC+ `7 ü * blueColor ° d ONLN dN7 `C ü * cyanColor ° d ONLN dYC `O ¥ * magentaColor ° d ONLN dgO `[ ≠ * yellowColor ° d ONLN dsg <sÏ (è ZXTo generate color all you need to do is set the foreground and background colors before ° d ONLN dÀgÏs˛ (è
you ° d ONLN dœs <t (õ ZCbegin drawing (initially they are set to blackColor foreground and ° d ONLN dst˛ (õíwhiteColor background). To ° d ONLN d-Ä <å ˙ (® Z(do this you call the QuickDraw routines ° d ONLN dU ˙ã9 )æ ForeColor ° d ONLN d^Ä9åR )? and ° d ONLN dcRãë ) BackColor ° d ONLN dlÄëå· )? as described in ° d ONLN d}Ä·å˛ )PInside ¡ X¡
(÷ ZPR 1 - Color Printing (÷1 ) of 4 (Ï ZM.PR.ColorPrinting ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) I * Macintosh ° d ONLN d I ) _ )1. If ° d ONLN d _ )⁄ )Fyou are using QuickDraw pictures, make sure you set the foreground and ° d ONLN d U * 6 ¡ ( R 6"background colors before you call ,
from them. ° d ONLN dÆ Ä å D *Caveats ° d ONLN d∂ ò §Ñ *GWhen printing a large area of more than one color you will encounter a ° d ONLN d˝ òÑ §⁄ ( ¿¢problem with the ° d ONLN d § ∞ – ( à 6'ribbon. When you print a large area of ° d ONLN d5 § – ∞⁄ )∏8one color, the printer’s pins pick up the color from the ° d ONLN dn ∞ º > ( ÿ 6back of ° d ONLN dv ∞ > º⁄ )&Vthe ribbon. When another large area of color is printed, the pins deposit the previous ° d ONLN dÕ º » 3 ( ‰ 6color ° d ONLN d” º 3 »⁄ )Yonto the back of the ribbon. Eventually the first color will come through to the front of ° d ONLN d- » ‘# ( 68the ribbon, contaminating the second color. You can get ° d ONLN de »# ‘⁄ ( A'the same kind of effect if you set, for ° d ONLN dç ‘ ‡Œ ( ¸ 6[example, a foreground color of yellow and a background color of blue. The ribbon will pick ° d ONLN dË ‘Œ ‡⁄ ( ¸Ïup ° d ONLN dÎ ‡ Ï@ ( 6@the blue as it tries to print yellow on top of it. This problem ° d ONLN d+ ‡@ Ï⁄ (^"is partially alleviated in the 2.3 ° d ONLN dN Ï ¯q ( 6Jversion of the ImageWriter driver by using a different printing technique. ° d ONLN dô *3The ribbon goes through the printer rather quickly ° d ONLN dÃ⁄ )Ô*when printing large areas. When the ribbon ° d ONLN d˜ ? (8 6>comes through the second time the colors don’t look too great.
° d ONLN d64 C £ *'Part 2, LaserWriters ° d ONLN dKO ^ì *Using the PostScript ‘image’ Operator to Print Halftones
° d ONLN dÑj v i *
About ‘image’ ° d ONLN díÇ é ‘ *&The PostScript image operator is used ° d ONLN d∏Ç ‘é⁄ )º2to send Bitmaps or Pixmaps to the LaserWriter. The ° d ONLN dÎé ö (∂ 66image operator can handle depths from 1 to 8 bits per ° d ONLN d!éö⁄ )˛(pixel. Our current LaserWriters can only ° d ONLN dJö ¶P (¬ 6Bimage about twenty shades of gray, but the printed page will look ° d ONLN dåöP¶⁄ (¬n like there’s more. Being that ° d ONLN d™¶ ≤¢ (Œ 6Vthe image operator is still a PostScript operator, it expects its data in the form of ° d ONLN d ¶¢≤⁄ (Œ¿ hexidecimal ° d ONLN d ≤ æ ¬ (⁄ 6$bytes. The bytes are represented by ° d ONLN d0≤ ¬æ⁄ )™7two ASCII characters(0-9,A-F). The image operator takes ° d ONLN dhæ i (Ê 6these parameters:
° d ONLN d{÷ <· +$(width height depth matrix image-data
° d ONLN d§Ï ¯g ( 6?The first three are the width, height, and depth of the image, ° d ONLN d„Ïg¯⁄ (Öand the matrix is the ° d ONLN d˘¯ ñ ( 6transformation matrix to ° d ONLN d¯ ñt )~*be applied to the current matrix. See the ° d ONLN d<¯t⁄ )fiPostScript Language ° d ONLN dP n (, 6Reference Manual ° d ONLN d` nY )V/ for more information. The image data is where ° d ONLN dèY⁄ )Îthe actual hex data should ° d ONLN d™ 7 (8 6?go. Instead of inserting the data between the first parameters ° d ONLN dÈ7 ⁄ (8U$and the image operator itself, it is ° d ONLN d (æ (D 6[better to use a small, PostScript procedure to read the data starting from right after the ° d ONLN d i æ(⁄ (D‹image ° d ONLN d o( 4 Ñ (P 6operator. For example:
° d ONLN d á@ <K √ +$ 480 8 [640 0 0 480 0 0] ° d ONLN d §J <U ˙ *
&{currentfile picstr readhexstring pop} ° d ONLN d ÃT <_ U *
image ° d ONLN d ”^ <i √ *
FF 00 FF 00 FF 00 FF 00 ...
° d ONLN d Ôt ÄO (ú 6CIn the above example, the width of the image is 640, the height is ° d ONLN d
2tOÄ⁄ (úm 480, and the depth is 8. The ° d ONLN d
OÄ åΩ (® 6Zmatrix (enclosed in brackets) is setup to draw the image starting at QuickDraw’s 0,0 (top ° d ONLN d
(÷ 62 ) of 4 (÷üPR 1 - Color Printing +M.PR.ColorPrinting ˇÃ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d < ) ’ ( E Z page), and with no scaling. The ° d ONLN d ’ )˛ )ô>PostScript code (enclosed in braces) is not executed. Instead, ° d ONLN d _ ) < 5 É ( Q Zit is passed to ° d ONLN d o ) É 5˛ )GOthe image operator, and the image operator will call it repeatedly until it has ° d ONLN d ø 5 < A Á ( ] Z"enough data to draw the image. In ° d ONLN d · 5 Á A˛ )´7this case, it will be expecting 640*480 bytes. When the ° d ONLN d A < MH ( i Z:image operator calls the procedure, it does the following: ° d ONLN dT Y N e X +1. ° d ONLN dW Y ` e+ )+Pushes the current file which in this case ° d ONLN dÇ Y+ e⁄ )À#is the stream of data coming to the ° d ONLN d¶ e ` q∂ ( ç ~ILaserWriter over AppleTalk. This is the first parameter to readhexstring. ° d ONLN d } N â X ( • l2. ° d ONLN dÛ } ` â )*Next picstr is pushed. picstr is a string ° d ONLN d } â⁄ )π'variable defined to hold one row of hex ° d ONLN dE â ` ï& ( ± ~-data. The PostScript to create the picstr is: ,
(/ Z-source color table into PostScript grayscale ° d ONLN d"
˛ )Œ3values. This is actually easy to do using the Color ° d ONLN dV < P (; Z<Manager. First create a table that can hold 512 bytes. This ° d ONLN díP ˛ (;n$is 2 bytes for each color value from ° d ONLN d∑ <+ (G Z/0 to 255. Since PostScript wants the values in ° d ONLN dÊ +˛ )‹.ASCII, you need two characters for each pixel. ° d ONLN d + <7~ (S ZDNow loop through the colors in the color table. Call Index2Color to ° d ONLN d Y+~7˛ (Súget the real RGB color for ° d ONLN d t7 <C ˚ (_ Z%that index, and then call RGB2HSL to ° d ONLN d ô7 ˚C˛ )ø2convert the RGB color into a luminance value. This ° d ONLN d ÃC <O m (k Z value will ° d ONLN d ◊C mO˛ )1Qbe expressed as a SmallFract which can then be scaled into a value from 0 to 255. ° d ONLN d
)O <[ Ω (w ZThis value should then be ° d ONLN d
CO Ω[˛ )ÅAconverted to ASCII, and stored at the appropriate location in the ° d ONLN d
Ö[ <gÙ (É Z^table. When you are done, you should be able to use a pixel value as an index into your table ° d ONLN d
„[Ùg˛ (Éof ° d ONLN d
Êg <sÔ (è Z]PostScript color values. For each pixel in the image, send two characters to the LaserWriter. ¡ X¡
*GPR 1 - Color Printing (÷3 ) of 4 (Ï ZM.PR.ColorPrinting ˇ\ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) x *Sending the Data ° d ONLN d 5 A Î */Once you have set up the color table, all that ° d ONLN d @ 5 Î A⁄ )”4left to do is to loop through all of the pixels, and ° d ONLN d u A M Œ ( i 6(send their PostScript representation to ° d ONLN d ù A Œ M⁄ )∂7the LaserWriter. There are a couple of ways to do this. ° d ONLN d ’ M Y ( u 6:First is to use the low-level Print Manager interface and ° d ONLN d M Y⁄ ( u>&stream the PostScript using the stdBuf ° d ONLN d6 Y e ˙ ( Å 6-PrCtlCall. Although this seems like it would ° d ONLN dc Y ˙ e⁄ )‚-be the fastest way, the latest version of the ° d ONLN dë e qL ( ç 6?LaserWriter driver (5.0) converts all low-level calls to their ° d ONLN d– eL q⁄ ( çj high level equivalent before ° d ONLN dÌ q } ı ( ô 6/executing them. Because of this, the low-level ° d ONLN d q ı }⁄ )›2interface is no longer faster than the high level. ° d ONLN dO } â ∑ ( • 6!In an FKEY I have written, I use ° d ONLN dp } ∑ â⁄ )ü=the high-level Print Manager interface, and send the data via ° d ONLN dÆ â ïf ( ± 6@the PostScriptHandle PicComment. This way, I can buffer a large ° d ONLN dÓ âf ï⁄ ( ±Ñamount of data, before ° d ONLN d ï ° ¸ ( Ω 62actually sending it. Using this technique, I have ° d ONLN d7 ï ¸ °⁄ )‰-been able to image a Mac II screen in about 5 ° d ONLN de ° ≠î ( … 6Mminutes on a LaserWriter Plus, and about 1.5 minutes on a LaserWriter II NTX. ° d ONLN d≥ — › Ç *0Further Reference: ¸ 4 ¸˘ ° d ONLN dΔ fi * Í . +
• ° d ONLN d» fi < Í r ) QuickDraw ° d ONLN d“ Í * ˆ . ( H• ° d ONLN d‘ Í < ˆ £ )The Printing Manager ° d ONLN dÈ ˆ * . ( H• ° d ONLN dÎ ˆ <G )3PostScript Language Reference Manual, Adobe Systems ¡ 4¡˘
(÷ 64 ) of 4 (÷üPR 1 - Color Printing +M.PR.ColorPrinting ˇû ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åc ( õ Z"PR 2 - Device-Independent Printing
° d ONLN d # Ä < è s *Printing
° d ONLN d - õ < ß t * Revised by: ° d ONLN d : õ≈ ߲ ( √„
KMany of the fields in the print record are undocumented, and, as we change ° d ONLN d˚\fihÏ (Ѹthe ° d ONLN dˇh [tå (ê y=internal architecture of the Printing Manager to accommodate ° d ONLN d<håtÏ (ê™new devices, those ° d ONLN dOt [Ä (ú y)undocumented fields are likely to change. ° d ONLN dyå Nò R (¥ l• ° d ONLN d{å [ò )
° d ONLN d˚ < « * To be compatible with future ° d ONLN d-˚ «˛ )ãFprinter-like devices, it is essential that your application print in a ° d ONLN dt < ú (/ Zdevice-independent ° d ONLN dá ú˛ )`Fmanner. Avoid testing undocumented fields, setting fields in the print ° d ONLN dŒ < ^ (; Zrecord ° d ONLN d’ ^ ˛ )"Tdirectly and bypassing the existing print dialogs. Use the Printing Manager dialogs, ,
Courier ° d ONLN d* <+ ê (H Z PrintDefault ° d ONLN d6 ê, ß )T and ° d ONLN d; ß+ Ì )
PrValidate ° d ONLN dE Ì,ç )F$ to set up the print record for you. ° d ONLN djP <\ ¶ (x ZFurther Reference: { X{ ° d ONLN d}] Ni R +
• ° d ONLN d] `i « )The Printing Manager ¡ X¡
(÷ Z"PR 2 - Device-Independent Printing (÷1 ) of 1 (Ï Z M.PR.DeviceIndependentPrinting ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øT ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åfi ( õ Z.PR 3 - Document Names and the Printing Manager
° d ONLN d / Ä < è s *Printing
° d ONLN d 9 õ < ß t * Revised by: ° d ONLN d F õ≈ ߲ ( √„
March 1988 ° d ONLN d Q ß < ≥ q ( œ Z Written by: ° d ONLN d ] ß Ñ ≥ « )H
Bryan Stearns ° d ONLN d k ßœ ≥˛ ( œÌ July 1987 ° d ONLN d u ø < À¡ ( Á ZROur compatibility testing for LaserShare (Apple’s LaserWriter spooler) has turned ° d ONLN d « ø¡ À˛ ( Áfl up a number ° d ONLN d ” À < ◊ ò ( Û Zof applications that ° d ONLN d Ë À ò ◊˛ )\Gdo not provide the Printing Manager with a document name; although this ° d ONLN d0 ◊ < „Y ( ˇ ZBfeature is not required, it is nice for users that share printers. X ° d ONLN ds ¸ < *% Some printers (usually those ° d ONLN dê ¸ ˛ )é=that are shared between many users, like the LaserWriter) can ° d ONLN dŒ <á (0 ZBprovide the names of the users who are printing and the documents ° d ONLN dᲠ(0•that are being printed to ° d ONLN d* < È (< Z'others interested in using the printer. ° d ONLN dS, <8 *TIf the chosen printer uses a document name, the Printing Manager gets the name from ° d ONLN dß,8˛ (Tthe ° d ONLN d´8 <Dß (` ZJfrontmost window’s title. If there is no front window, or if the window’s ° d ONLN dı8ßD˛ (`≈title is empty, the ° d ONLN d D <P (l Z'Printing Manager defaults to “unknown.” ° d ONLN d1\ <h Ò *"This method was chosen because it ° d ONLN dS\ Òh˛ )µ5works most transparently to applications; however, it ° d ONLN dâh <t ’ (ê Z won’t work if your application ° d ONLN d®h ’t˛ )ô9doesn’t display windows when printing (for instance, many ° d ONLN d‚t <Ä ˆ (ú Z(applications that use windows for their ° d ONLN d
t ˆÄ˛ )∫3documents do not open their documents when printing ° d ONLN d>Ä <å (® Z)in response to a Finder “Print” command). ° d ONLN dhò <§ ≥ *As a general solution to ° d ONLN dÅò ≥§˛ )w?this problem, you can put up a window containing a message like ° d ONLN d¡ß <≥ _ (œ Z“Press ° d ONLN d»§ _¥ j )# ° d ONLN d…ß j≥ ) !–. to cancel printing”, and give ° d ONLN dÍß≥˛ )õ3it the document’s title. If the window is one that ° d ONLN d ¥ <¿ « (‹ Z doesn’t have a title bar (like ,
Courier ° d ONLN d=≥ «ø ˇ )ãdBoxProc ° d ONLN dE¥ ˇ¿m )8), this title will not be ° d ONLN d_¥m¿˛ )n displayed. MacApp takes this ° d ONLN d|¿ <ÃH (Ë Z8approach. If for some reason you don’t want to put up a ° d ONLN d¥¿HÃ˛ (Ëf%visible window, you can create a tiny ° d ONLN d⁄à <ÿ f (Ù Zwindow ° d ONLN d·Ã fÿ˛ )*Tand hide it behind the menu bar: for instance, global coordinates of (1,1,2,2). Make ° d ONLN d6Ÿ <Â É ( Zsure you use a ° d ONLN dEÿ ɉ ¬ )G plainDBox ° d ONLN dNŸ ¬ÂR )?!, so that no title will be drawn ° d ONLN doŸR² )ê%(otherwise, in the unlikely case that ° d ONLN dï <Ò⁄ (
ZTa user is using a Macintosh II with two stacked screens, main screen on the bottom, ° d ONLN dÈÂ⁄Ò˛ (
¯ the title ° d ONLN dÛÒ <˝ Ó ( Z&might be visible on the upper screen). ° d ONLN d
<" *.Since the Printing Manager checks the name at ° d ONLN dH "h )Ê
PrValidate ° d ONLN dR
hl )F ° d ONLN dS
lû ) time, call ° d ONLN d^ û‰ )2
PrValidate ° d ONLN dh
‰˛ )F after ° d ONLN do <" Ç (? Z
PrCloseDoc ° d ONLN dy Ç# ‚ )F and before the next ° d ONLN dé ‚"! )` PrOpenDoc ° d ONLN dó!#¶ )?, if you want unique names. ° d ONLN d¥/ <;fl (W ZXA number of applications set the document name in the print record directly. You should ° d ONLN d /fl;˛ (W˝not do ° d ONLN d; <G§ (c ZPthis because a) not all printers support this field, and b) none are guaranteed ° d ONLN dc;§G˛ (c¬to support it in the ° d ONLN dxG <S õ (o Zfuture. (Apple does ° d ONLN dåG õS˛ )_Lnot guarantee that internal fields of the Printing Manager’s data structures ° d ONLN dŸS <_— ({ ZXwill remain the same; the Printing Manager is targeted for substantial internal change!) ° d ONLN d 2k <w ¶ *Further Reference: ñ Xñ ° d ONLN d Ex NÑ R +
(÷ Z.PR 3 - Document Names and the Printing Manager (÷1 ) of 1 (Ï ZM.PR.DocumentNames ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø® ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å≠ ( õ Z*PR 4 - LaserWriter Optimization Techniques
° d ONLN d + Ä < è s *Printing
° d ONLN d 5 õ < ß t * Revised by: ° d ONLN d A õ Ñ ß )HPete “Luke” Alexander ° d ONLN d W õæ ߲ ( √‹ October 1990 ° d ONLN d d ß < ≥ q ( œ Z Written by: ° d ONLN d p ß Ñ ≥ – )HGinger Jernigan ° d ONLN d Ä ß∏ ≥˛ ( œ÷
February 1986 ° d ONLN d é ø < À˜ ( Á Z]This Technical Note discusses techniques for optimizing code for printing on the LaserWriter. ° d ONLN d Ï À < ◊ ô * Changes since ° d ONLN d ˙ À ô ◊  )] March 1988: ° d ONLN d À  ◊˛ )L0 Updated the “Printable Paper Area” and “Memory ° d ONLN d6 ◊ < „0 ( ˇ Z5Considerations” sections as well as the printer IDs, ° d ONLN dk ◊0 „˛ )Ù(moved the error messages from the end of ° d ONLN dî „ < Ô £ ( Zthe Note to Technical ° d ONLN d™ „ £ Ô˙ )g@Note #161, A Printing Loop That Cares…, and removed the “Spool-A ° d ONLN dÍ „˙ Ô˛ ( - ° d ONLN dÎ Ô < ˚ ( Z-Page/Print-A-Page” section because Technical ° d ONLN d Ô ˚˙ )‰)Note #125, Effect of Spool-A-Page/Print-A ° d ONLN dA Ô˙ ˚˛ )⁄- ° d ONLN dB ˚ <b (# Z>Page on Shared Printers, already thoroughly covers this topic. 2 X2
° d ONLN dÅ, <; è *4 Introduction
° d ONLN déG <S — * Although the Printing Manager ° d ONLN d¨G —S˛ )ï?was originally designed to allow application code to be printer ° d ONLN dÏS <_\ ({ Z9independent, there are some things about the LaserWriter ° d ONLN d%S\_˛ ({z that, in some cases, have to be ° d ONLN dE_ <kô (á ZDaddressed in a printer dependent way. This Note describes what the ° d ONLN dâ_ôk˛ (á∑LaserWriter can and ° d ONLN dùk <w ^ (ì Zcannot ° d ONLN d§k ^w˛ )"Tdo, memory considerations, speed considerations, as well as other things you need to ° d ONLN d˘w <É¿ (ü ZRwatch out for if you want to make your printing more efficient on the LaserWriter.
° d ONLN dLõ <™é *'/How To Determine The Currently Selected Printer
° d ONLN d|∑ <√ i * With the ° d ONLN dÖ∑ i√? )-)addition of new picture comments and the ,
Courier ° d ONLN dÆ∂?¬~ )÷ PrGeneral ° d ONLN d∑∑~√˛ )? procedure, an application ° d ONLN d“√ <œb (Î Z9should never need to know the type of device to which it ° d ONLN d √bœ˛ (ÎÄ is connected. However, some ° d ONLN d(œ <€| (˜ ZFdevelopers feel their application should be able to take advantage of ° d ONLN dnœ|€˛ (˜ö all of the features provided ° d ONLN d〠<Á% ( Z3by a particular device, not just those provided by ° d ONLN dæ€%Á˛ )È,the Printing Manager, and in doing so, these ° d ONLN dÎÁ <Ûn ( Z<developers produce device-dependent applications, which can ° d ONLN d'ÁnÛ˛ (å produce unpredictable results ° d ONLN dEÛ <ˇ
( Z,third-party and new Apple printing devices. ° d ONLN dqÛ
ˇ˛ )—0 For this reason, Apple strongly recommends that ° d ONLN d¢ˇ < ~ (' ZCyou use only the features provided by the Printing Manager, and do ° d ONLN d¡~ ˛ ('únot try to use unsupported ° d ONLN d < Ü (3 Zdevice features. ° d ONLN d# </∫ *PEven though there is no supported method for determining a device’s type, there ° d ONLN da#∫/˛ (Kÿ
is one method ° d ONLN do/ <; z (W Z
described in ° d ONLN d|/ z; ∂ )>
the original ° d ONLN dâ/ ∂; )<Inside Macintosh ° d ONLN dö/;˛ )X0that still works for ImageWriter and LaserWriter ° d ONLN dÀ; <G “ (c Z!printer drivers. This method is ° d ONLN dÏ; “G ‰ )ñnot ° d ONLN dÔ; ‰G ) supported, ° d ONLN d˚; G˛ )90meaning that at some point in the future it will ° d ONLN d,G <S! (o Z0no longer work. If you use this method in your ° d ONLN d\G!S˛ )Â/application, it is up to you to weigh the value ° d ONLN dåS <_# ({ Z4of the feature against the compatibility risk. The ° d ONLN d¿S#_˛ )Á+following method works for all ImageWriter, ° d ONLN dÏ_ <k z (á Z ImageWriter ° d ONLN d¯_ zk0 )>'II, and LaserWriter (original, Plus, II
° d ONLN d _0k= )∂NT
° d ONLN d !_=kM )
, II
° d ONLN d %_Mka )NTX
° d ONLN d (_ak˛ )!) drivers. Since all new devices ° d ONLN d Jk <wß (ì ZIreleased from Apple and third-party developers have their own unique ID, ° d ONLN d ìkßw˛ (ì≈it is up to you to ° d ONLN d ¶w <ÉÜ (ü ZFdecide what to do with an ID that your application does not recognize. ¡ X¡
° d ONLN dÌ ò §0 ), and ° d ONLN dÛ § Ñ ∞ Î ( Ã ¢Personal LaserWriter
° d ONLN d § Î ∞ ¯ )gNT
° d ONLN d §i ∞o )~3 ° d ONLN d
∞ Ñ º « ( ÿ ¢LaserWriter II
° d ONLN d ∞ « º ‘ )CSC
° d ONLN d ∞ ‘ ºB )
, Personal LaserWriter
° d ONLN d4 ∞B ºO )nSC
° d ONLN d7 ∞i ºo )'4 ° d ONLN d9 º Ñ » — ( ‰ ¢ImageWriter LQ ° d ONLN dH ºi »o )Â5 Á † Áü ° d ONLN dJ · Ì∫ ( 6YIf you are using the low-level Printing Manager interface, there is no dependable way of ° d ONLN d£ ·∫ Ì⁄ ( ÿgetting ° d ONLN d´ Ì ˘ … ( 6"the wDev information. You should ° d ONLN dÕ Ì … ˘ € )±not ° d ONLN d– Ì € ˘ fl ) ° d ONLN d— Ì fl ˘⁄ )1attempt to determine the device ID when using the ° d ONLN d ˘ » (! 6%low-level Printing Manager interface.
° d ONLN d) ,# *'$Using QuickDraw With the LaserWriter
° d ONLN d–E ‡Qû +$, which is in the LaserWriter ROM. ° d ONLN dÙEûQ⁄ )æ Most of the ° d ONLN d Q ] M (y 6 operations ° d ONLN d Q M]⁄ )5Oavailable in QuickDraw are available in PostScript, with a few exceptions. The ° d ONLN d[] i (Ö 62LaserWriter driver does not support the following: ° d ONLN dév *Ç . +• ° d ONLN dêu 7Å L )
XOR ° d ONLN dìv LÇ c ) and ° d ONLN dòu cÅ ç )NotXOR ° d ONLN dûv çÇ ⁄ )* transfer modes. ° d ONLN dØÉ *è . (´ H• ° d ONLN d±É 7è w )
The grafverb ° d ONLN dæÇ wé ° )@invert ° d ONLN dƒÉ °è • )*. ° d ONLN dΔê *ú . (∏ H• ° d ONLN d»è 7õ } )
_SetOrigin ° d ONLN d“ê }ú û )F calls ° d ONLN dŸê ûú √ )!within ° d ONLN d‡è √õ )%
for how to ° d ONLN dÌ¡ 7Õ ± (È Ucreate off-screen bitmaps. ° d ONLN dÕ *Ÿ . (ı H• ° d ONLN d
Õ 7Ÿ )
-Clip regions should be limited to rectangles. ° d ONLN d8Ÿ *Â . ( H• ° d ONLN d:Ÿ 7Â U )
There ° d ONLN d@Ÿ UÂ∂ ) Jis a small difference in character widths between screen fonts and printer ° d ONLN dã 7Ò: (
U9fonts. Only the end points of text strings are the same.
° d ONLN d≈ ; (4 6'What You See Is Not Always What You Get
° d ONLN dÌ$ 0î *JUnfortunately, what you see on the screen is not always what you get. If ° d ONLN d7$î0⁄ (L≤
you are using ° d ONLN dE0 < E (X 6 standard ° d ONLN dN0 E<⁄ )-Sgraphic objects, like rectangles, circles, etc., the object is the same size on the ° d ONLN d¢< H π (d 6$LaserWriter as it is on the screen. ° d ONLN dΔ< πH⁄ )°; There are, however, two types of objects where this is not ° d ONLN dH T ó (p 6 the case: text and bitmaps. ° d ONLN d ` l - *The ° d ONLN d#` -l⁄ )Yearlier noted difference between the widths of characters on the screen and the widths of ° d ONLN d}l x (î 66characters on the printer is due to the difference in ° d ONLN d≥lx⁄ (î8%resolution. However, to maintain the ° d ONLN dŸx Ñ ö († 6 integrity of line breaks, the ° d ONLN d˜x öÑ⁄ )ÇAdriver changes the word and character spacing to maintain the end ° d ONLN d 9Ñ ê– (¨ 6apoints of the lines as specified. What this all means is that you cannot count on the positions ° d ONLN d öÑ–ê⁄ (¨Óor ¡ 4¡˘
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d < )@ ( E Z8the widths of printed characters being exactly the same ° d ONLN d 8 @ )˛ ( E^'as they are on the screen. This is why ° d ONLN d ` * < 6 Æ ( R Zin the original MacDraw
° d ONLN d w ( Æ 3 µ ( O î
° d ONLN d x * µ 6Ù +G, for example, if one carefully places text and a rectangle and prints ° d ONLN d ø *Ù 6˛ ( Rit, ° d ONLN d √ 6 < B N ( ^ Zthe ° d ONLN d « 6 N B˛ )Utext sometimes extends beyond the bounds of the rectangle on the printed page. If an ° d ONLN d B < Nå ( j ZGapplication does its own line layout (i.e., positions the words on the ° d ONLN dd Bå N˛ ( j™line itself), then it may ° d ONLN d~ N < ZL ( v Z8want to disable the LaserWriter’s line layout routines. ° d ONLN d∂ NL Z˛ ( vj# To disable these routines, use the ,
Courier ° d ONLN d⁄ Z < f ó ( É Z
LineLayoutOff ° d ONLN dÁ [ ó g √ )[ picture ° d ONLN d [ √ g˛ ),9comment described in the LaserWriter Reference Manual and ° d ONLN d* g < só ( è ZDTechnical Note #91, Optimizing for the LaserWriter—Picture Comments. ° d ONLN do < ã/ *5The sole exception to this rule is if an application ° d ONLN d§ / ã˛ )Û&is running on 128K ROMs or later. The ° d ONLN dÀ ã < ó‚ ( ≥ ZW128K ROM Font Manager supports the specification of fractional pixel widths for screen ° d ONLN d" ã‚ ó˛ ( ≥ fonts, ° d ONLN d) ó < £ Ä ( ø Zincreasing the ° d ONLN d8 ó Ä £˛ )DRscreen to printer accuracy. This fractional width feature is disabled by default. ° d ONLN då § < ∞ Á ( à Z&To enable it, an application can use ° d ONLN d≤ £ Á ØP )´_SetFractEnable ° d ONLN d¡ §P ∞ë )i, after calling ° d ONLN d— £ë Ø◊ )A
_InitFonts ° d ONLN d€ §◊ ∞€ )F. ° d ONLN d› º < » è ( ‰ ZApplications can ° d ONLN dÓ º è »˛ )SNuse picture comments to left-, right-, or center-justify text. Only the left, ° d ONLN d= » < ‘* ( Z2right, or center end points are accurate. If the ° d ONLN do »* ‘˛ )Ó,text is fully justified, both end points are ° d ONLN dú ‘ < ‡ ú ( ¸ Zaccurate. Technical ° d ONLN d± ‘ ú ‡˛ )`DNote #91, Optimizing for the LaserWriter—Picture Comments, discusses ° d ONLN dˆ ‡ < Ï Æ ( Zthese picture comments.
° d ONLN d < ⁄ *'Memory Considerations
° d ONLN d$ <+ Ô *&To print to the LaserWriter, you need ° d ONLN dJ Ô+˛ )≥5to make sure that you have enough memory available to ° d ONLN dÄ+ <7Ï (S Z_load the driver’s code. The best way to do this is to have all the code you need for printing ° d ONLN dfl+Ï7˛ (S
in a ° d ONLN d‰7 <C6 (_ Z3separate segment and unload everything else. When ° d ONLN d76C˛ )˙)you print to the LaserWriter you are only ° d ONLN dAC <OL (k Z<able to print in Draft mode. You are not able to spool (as ° d ONLN d}CLO˛ (kj$the ImageWriter does in the standard ° d ONLN d¢O <[ » (w Z or high-quality settings), and ° d ONLN d¡O »[˛ )åAyour print code, data, and the driver code have to be resident in ° d ONLN d[ <g g (É Zmemory. ° d ONLN d s <Ÿ *QIn terms of memory requirements, there is not any magic number that always works ° d ONLN d\sŸ˛ (õ˜with all ° d ONLN de <ã≤ (ß ZSprinter drivers (including third-party printer drivers) that are available for the ° d ONLN d∏≤ã˛ (ß–Macintosh. To ° d ONLN d«ã <ó2 (≥ Z2make sure there is enough memory available during ° d ONLN d˘ã2ó˛ )ˆ)print time, you should make your printing ° d ONLN d#ò <§Ω (¿ ZPcode a separate segment and swap out all unwanted code and data before you call ° d ONLN dsóΩ£Ó (¿€_PrOpen ° d ONLN dzòÓ§Ú )1.
° d ONLN d|º <À … (Á ZPrintable Paper Area
° d ONLN dë◊ <„| *BOn the LaserWriter there is a 0.45-inch border that surrounds the ° d ONLN d”◊|„˛ (ˇöprintable area of the paper ° d ONLN dÔ„ <Ô» ( ZV(this is assuming an 8.5” x 11” paper). If you select the “Larger Print Area” option ° d ONLN d E„»Ô˛ ( Ê in the Page ° d ONLN d QÔ <˚ § ( ZSetup dialog box, the ° d ONLN d gÔ §˚˛ )hIborder changes to 0.25 of an inch. This printable area is different than ° d ONLN d ±˚ <ï (# ZLthe available print area of the ImageWriter. An application cannot print a ° d ONLN d ˝˚ï˛ (#≥larger area because of ° d ONLN d
< { (/ Z the memory ° d ONLN d
{˛ )?HPostScript needs to image a page. PostScript takes the amount of memory ° d ONLN d
h < Î (; Z%available in the printer and centers ° d ONLN d
ç Î ˛ )Ø3it on the paper, and there is not enough RAM in the ° d ONLN d
¡ <+ (G Z.LaserWriter to image an entire sheet of paper.
° d ONLN d
C <R Å *'
Page Sizes
° d ONLN d
˚^ <j√ *OMany developers have expressed a desire to support page sizes other than those ° d ONLN d J^√j˛ (Ü· provided by ° d ONLN d Vj <v ‘ (í Z!the Apple printer drivers. Even ° d ONLN d wj ‘v˛ )ò<though some devices can physically support other page sizes, ° d ONLN d ¥v <Ç ã (û Zthere is no way ° d ONLN d ƒv ãDz )OMfor an application to tell the driver to use this size. With the ImageWriter ° d ONLN d Ç <éx (™ ZHdriver, it is possible to modify certain fields in the print record and ° d ONLN d ZÇxé˛ (™ñ expand the printable area of ¡ X¡
° d ONLN d )ï *Mthe page. However, each of the Apple drivers implements the page sizes in a ° d ONLN d M ï )⁄ ( E≥different way. ° d ONLN d ] ) 5 ñ ( Q 6No one method works for ° d ONLN d u ) ñ 5⁄ )~Dall drivers. Because of this difference, it is strongly recommended ° d ONLN d ∫ 5 AN ( ] 6Cthat applications do not attempt to change the page sizes provided ° d ONLN d ˝ 5N A⁄ ( ]l in the “Style” dialog box. If ° d ONLN d A M î ( i 6your application currently ° d ONLN d7 A î M⁄ )|Dsupports page sizes other than those provided by the printer driver, ° d ONLN d| M YΔ ( u 6^you are taking a serious compatibility risk with future Apple and third-party printer drivers.
° d ONLN d€ q Ä • *'Speed Considerations
° d ONLN d å ò ˛ *3Although the LaserWriter is relatively fast, there ° d ONLN d# å ˛ ò⁄ )Ê-are some techniques an application can use to ° d ONLN dQ ò § π ( ¿ 6 ensure its maximum performance. ° d ONLN dq ± * Ω . +• ° d ONLN ds ± 7 Ω Q )
Try ° d ONLN dw ± Q Ωl )0to avoid using the QuickDraw Erase calls (e.g., ,
Courier ° d ONLN dß ∞l º≤ ( Ÿä
_EraseRect ° d ONLN d± ±≤ Ω∂ )F, ° d ONLN d≥ Ω 7 … } ( Ê U
_EraseOval ° d ONLN dΩ æ } ≠ )F
, etc.). It ° d ONLN d æ ≠ ∂ )08takes a lot of time to handle the erase function because ° d ONLN d 7 ÷D ( Ú U;every bit (90,000 bits per square inch) has to be cleared. ° d ONLN d> D ÷∂ ( Úb Erasing is unnecessary ° d ONLN dV ÷ 7 ‚Ä ( ˛ UEbecause the paper does not need to be erased the way the screen does. ° d ONLN dú Ó * ˙ . ( H• ° d ONLN dû Ó 7 ˙/ )
7Printing patterns takes time, since the bitmap for the ° d ONLN d’ Ó/ ˙∂ )¯ pattern has to be built. The ° d ONLN dÛ ˚ 7 _ (# U patterns ° d ONLN d¸ ˙ _ Ç )(black ° d ONLN d ˚ Ç â )#, ° d ONLN d ˙ â ¨ )white ° d ONLN d ˚ ¨® )#7, and all the gray patterns have been optimized to use ° d ONLN d? ˚®∂ )¸the ° d ONLN dC 7û (/ UNPostScript gray scales. If you use a different pattern it works, but it just ° d ONLN dëû∂ (/ºtakes ° d ONLN dó 7 i (; UDlonger than usual. In addition, the patterns in driver version 3.0 ° d ONLN d€i ∂ (;áare rotated; they ° d ONLN dÌ 7+ √ (G U are not rotated in version 1.0. ° d ONLN d
7 *C . (_ H• ° d ONLN d7 7C ˜ )
)Try to avoid frequently changing fonts. ° d ONLN d87 ˜C∂ )¿)PostScript has to build each character it ° d ONLN dbC 7O¨ (k UNneeds either by using the drawing commands for the built-in LaserWriter fonts ° d ONLN d∞C¨O∂ (k or ° d ONLN d≥O 7[è (w UDby resizing bitmaps downloaded from screen fonts on the Macintosh. ° d ONLN d˜Oè[∂ (w≠As each ° d ONLN dˇ[ 7g q (É U
character is ° d ONLN d [ qg∂ ):Ebuilt, it is cached (if there’s room), so if that character is needed ° d ONLN dRg 7sá (è UEagain PostScript gets if from the cache. When the font changes, the ° d ONLN dógás∂ (è•
characters ° d ONLN d¢s 7r (õ UEhave to be built from scratch in the new font, which takes time. If ° d ONLN dÁsr∂ (õêthe font is not ° d ONLN d˜ 7ã ú (ß Uin the LaserWriter, it ° d ONLN d úã∂ )e:takes time to download it from the Macintosh. If the user ° d ONLN dIã 7ó Δ (≥ Uhas the option of choosing ° d ONLN ddã Δó∂ )è.fonts, you have no control over this variable; ° d ONLN dìó 7£` (ø U?however, if you control which fonts to use, keep this in mind. ° d ONLN d”∞ *º . (ÿ H• ° d ONLN d’∞ 7º x )
Avoid using ° d ONLN d·Ø xª ∞ )A_TextBox ° d ONLN dÈ∞ ∞º )8. It makes calls to ° d ONLN d˛Øª[ )e
_EraseRect ° d ONLN d∞[ºÜ )F, which ° d ONLN d∞ܺ∂ )+ slows the ° d ONLN dº 7»^ (‰ UAprinter, for every line of text it draws. You might want to use ° d ONLN d[º^»∂ (‰|a different method ° d ONLN dn… 7’ E (Ò Uof ° d ONLN dq… E’ ± )displaying text (e.g., ° d ONLN dà» ±‘ ˛ )l _DrawString ° d ONLN dì… ˛’ )M or ° d ONLN dó»‘Q ) _DrawText ° d ONLN d†…Q’∂ )?) or write your own ° d ONLN d¥÷ 7‚ p (˛ U version of ° d ONLN dø’ p· ® )9_TextBox ° d ONLN d«÷ ®‚ ≤ )8. ° d ONLN d…÷ ≤‚z )
( If an application is currently calling ° d ONLN dÒ’z·≤ )»_TextBox ° d ONLN d˘÷≤‚∂ )8, ° d ONLN d˚‚ 7Óm (
U@changing to another method of displaying text can improve speed ° d ONLN d ;‚mÓ∂ (
ãon the order of ° d ONLN d KÓ 7˙ m ( U five to one. ° d ONLN d X * . (. H• ° d ONLN d Z 7 p )
I, 78: (T U5get a speed improvement of approximately four to one. ° d ONLN d
D *P . (l H• ° d ONLN d
ÅD 7P H )
Do ° d ONLN d
ÑD HP∂ )Jnot use spool-a-page/print-a-page as some applications do when printing on ° d ONLN d
œP 7\ó (x UCthe ImageWriter. It slows things down considerably because of all ° d ONLN d Pó\∂ (xµof the ° d ONLN d \ 7h ì (Ñ Upreparation that has , Helvetica ° d ONLN d -[ ìi ñ )\ ° d ONLN d .\ ñh ¢ )to ° d ONLN d 1\ ¢h∂ ) 9be done when a job is initiated. Refer to Technical Note ° d ONLN d kh 7t é (ê U#125, Effect of ° d ONLN d {h ét∂ )W6Spool-A-Page/Print-A-Page on Shared Printers, for more ° d ONLN d ≤t 7Ä r (ú U information. ¡ 4¡˘
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d N * R ( F l• ° d ONLN d [ * { )
Using ,
Courier ° d ONLN d { ) ∫ ) _DrawChar ° d ONLN d ∫ *. )? to place every character ° d ONLN d + . *⁄ )t%to print can take a lot of time. One ° d ONLN d Q * [ 6 ( R y%reason, of course, is because it has ° d ONLN d v * 6⁄ )∂'to go through the bottlenecks for every ° d ONLN d û 6 [ Bπ ( ^ yPcharacter that is drawn. The other is that the printer driver does its best to ° d ONLN d Ó 6π B⁄ ( ^◊do line ° d ONLN d ˆ B [ N¥ ( j yGlayout, making the character spacing just right. If you are trying to ° d ONLN d= B¥ N⁄ ( j“position ° d ONLN dF N [ Zí ( v yFcharacters and the driver is trying to position characters too, there ° d ONLN då Ní Z⁄ ( v∞is conflict, and ° d ONLN dù Z [ fà ( Ç yPprinting takes much longer than necessary. In version 3.0 of the driver, there ° d ONLN dÌ Zà f⁄ ( ÇÍare ° d ONLN dÒ f [ r ( é y(picture comments that turn off the line ° d ONLN d f r⁄ )Ω(layout optimization, alleviating some of ° d ONLN dB r [ ~ ú ( ö y
the problem. ° d ONLN dO r ú ~Œ )A< Refer to Technical Note #91, Optimizing for the LaserWriter ° d ONLN dã rŒ ~⁄ ( öÏ— ° d ONLN då ~ [ ä ( ¶ y'Picture Comments, for more information.
° d ONLN d¥ ¢ < ± ˛ ( Õ Z Clipping Within Text Strings
° d ONLN d— Ω < … π *When clipping characters ° d ONLN dÍ Ω π …˛ )}Cout of a string, make sure that the clipping rectangle or region is ° d ONLN d. … < ’… ( Ò ZWgreater than the bounding box of the text you want to clip. The reason is that if you ° d ONLN dÖ …… ’˛ ( ÒÁ clip part of ° d ONLN dí ’ < ·l ( ˝ ZAa character (e.g., a descender), the clipped character has to be ° d ONLN d” ’l ·˛ ( ˝ä rebuilt, which takes time. In ° d ONLN dÚ · < Ìú ( ZLaddition, because of the difference between screen fonts and printer fonts, ° d ONLN d> ·ú Ì˛ ( ∫chances are that you ° d ONLN dS Ì < ˘o ( ZCcannot accurately clip the right characters unless you are running ° d ONLN dñ Ìo ˘˛ (çon the 128K ROMs and have ° d ONLN d∞ ˘ < – (! Z fractional pixel widths enabled.
° d ONLN d— <,# *'!When to Validate the Print Record
° d ONLN dÛ9 <E Ñ *To validate the ° d ONLN d9 ÑE ÿ )Hprint record, call ° d ONLN d8 ÿD )T
PrValidate ° d ONLN d 9 E˛ )F0. You need validation to check to see if all of ° d ONLN dQE <Qj (m ZBthe fields are accurate according to the current printer selected ° d ONLN dìEjQ˛ (mà and the current version of the ° d ONLN d≤R <^ æ (z Zdriver. You should call ° d ONLN dÀQ æ] )Ç
PrValidate ° d ONLN d’R^≤ )F when you have allocated a new ° d ONLN dÙR≤^˛ )Æprint record or ° d ONLN d_ <k” (á ZRwhenever you need to access information from the print record (i.e., when you get ° d ONLN dV^”jˆ (áÒrPage ° d ONLN d[_ˆk˛ )#). ° d ONLN d_l <x z (î Z
The routines ° d ONLN dlk zw « )> PrStlDialog ° d ONLN dwl «x fi )M and ° d ONLN d|k fiw+ ) PrJobDialog ° d ONLN dál+xA )M call ° d ONLN dçkAwá )
PrValidate ° d ONLN dóláxæ )F when they ° d ONLN d¢læx˛ )7are called, so ° d ONLN d±x <ÑC († Z9you do not have to worry about it if you use these calls.
° d ONLN dÎú <´ Ì *'Empty QuickDraw Objects
° d ONLN d∑ <√ ¬ *QuickDraw objects that are ° d ONLN d ∑ ¬√˛ )Ü@empty (i.e., they have no pixels in them) and are filled but not ° d ONLN d_√ <œ d (Î Zframed, ° d ONLN dg√ dœ˛ )(Qdo not print on the ImageWriter and do not show up on the screen; however, on the ° d ONLN dπœ <€ (˜ Z/LaserWriter they are real objects and do print. ¡ X¡
° d ONLN d ) Ç *Further Reference: H 4 H˘ ° d ONLN d * * 6 . +
• ° d ONLN d * < 6 ç )Inside Macintosh ° d ONLN d % * ç 6 ˝ )Q, Volume I, QuickDraw ° d ONLN d ; 6 * B . ( ^ H• ° d ONLN d = 6 < B ç )Inside Macintosh ° d ONLN d M 6 ç B2 )Q!, Volume II, The Printing Manager ° d ONLN d o B * N . ( j H• ° d ONLN d q B < N à ) LaserWriter Reference Manual ° d ONLN d é N * Z . ( v H• ° d ONLN d ê N < Z )$Technical Note M.IM.OffscreenBitMap— ° d ONLN d ∑ Z ` f +$ " Drawing Into An Off-Screen Bitmap ° d ONLN d ⁄ f * r . ( é H• ° d ONLN d ‹ f < r ˙ )"Technical Note M.IM.PictComments — ° d ONLN d r ` ~W +$ 0 Optimizing for the LaserWriter—Picture Comments ° d ONLN d2 ~ * ä . ( ¶ H• ° d ONLN d4 ~ < ä ⁄ ) Technical Note M.IM.Spooler — ° d ONLN dT ä ` ñn +$ 7 Effect of Spool-A-Page/Print-A-Page on Shared Printers ° d ONLN då ñ * ¢ . ( æ H• ° d ONLN dé ñ < ¢  ) Technical Note M.IM.PrintLoop — ° d ONLN d∞ ¢ ` Æ Ú +$ A Printing Loop That Cares… ° d ONLN dÕ Æ * ∫ . ( ÷ H• ° d ONLN dœ Æ < ∫d ):PostScript Language Reference, Adobe Systems, Incorporated ° d ONLN d
∫ * Δ . ( ‚ H• ° d ONLN d ∫ < Δ£ )FPostScript Language Tutorial and Cookbook, Adobe Systems, Incorporated ° d ONLN dS “ fi( ( ˙ 68MacDraw is a registered trademark of Claris Corporation. ° d ONLN då fi Í` * DPostScript is a registered trademark of Adobe Systems, Incorporated. ¡ 4¡˘
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < ÅB ( õ Z PR 5 - LaserWriter ROMs Bugs
° d ONLN d Ä < è s *Printing
° d ONLN d ' õ < ß t * Revised by: ° d ONLN d 3 õ Ñ ß – )HGinger Jernigan ° d ONLN d C õœ ߲ ( √Ì July 1987 ° d ONLN d M ß < ≥ g ( œ ZUpdated: ° d ONLN d W ß≈ ≥˛ ( œ„
March 1988 ° d ONLN d b ≥ < ø q ( € Z Written by: ° d ONLN d n ≥ Ñ ø – )HGinger Jernigan ° d ONLN d ~ ≥Œ ø˛ ( €ÏMay 1987 ° d ONLN d á À < ◊! ( Û Z/These are LaserWriter bugs that your users may ° d ONLN d ∂ À! ◊µ ) encounter when printing from ° d ONLN d ” Àµ ◊… )îany ° d ONLN d ÷ À… ◊˛ )
Macintosh ° d ONLN d · ◊ < „Å ( ˇ ZDapplication. These are for your information; you cannot code around ° d ONLN d% ◊Å „˛ ( ˇüthem. The bugs described ° d ONLN d> „ < Ô% ( Z/here occur in the 1.0 and 2.0 LaserWriter ROMs. X ° d ONLN dn < } *%
To determine ° d ONLN d{ }˛ )AOwhich ROMs their LaserWriter contains, users can look at the test page that the ° d ONLN dÀ < $ (< Z4LaserWriter prints at start-up time. In addition to ° d ONLN dˇ$ ˛ )Ë.other information (detailed in the LaserWriter ° d ONLN d. <, (H Z)user’s manual), the ROM version is shown ° d ONLN dW ,˛ )›-at the bottom of the line graph. The original ° d ONLN dÖ, <8- (T Z,LaserWriter contained version 1.0 ROMs. The ° d ONLN d±,-8˛ )Ò(currently shipping LaserWriter and those ° d ONLN d⁄8 <D\ (` Z:upgraded to the LaserWriter Plus contain version 2.0 ROMs. ° d ONLN dP <\ **These are some of the problems we know of: ° d ONLN d@h <t F *1. ° d ONLN dCh Nt• )NIf the level of paper in the paper tray is getting low, and the user prints a ° d ONLN dëh•t˛ (ê√document that will ° d ONLN d§t <Ä (ú Z-cause the tray to become empty, a PostScript ° d ONLN d—tIJ )÷0error may occur. This problem exists in both the ° d ONLN dÄ <å ¸ (® Z&1.0 and 2.0 LaserWriter ROMs and will ° d ONLN d(Ä ¸å )¿not ° d ONLN d+Äå≤ )" be fixed in the next ROM version. ° d ONLN dNò <§ F (¿ Z2. ° d ONLN dQò N§ )(If a user prints more than 15 copies of ° d ONLN dyò§˛ )∑1a document, a timeout condition may occur causing ° d ONLN d´§ <∞ Ñ (à Zthe print job to ° d ONLN dº§ Ñ∞˛ )HLabort. With LaserShare, this problem can occur with as few as 9 copies. This ° d ONLN d ∞ <º∂ (ÿ ZSproblem is a result of the LaserWriter turning AppleTalk off while it is printing. ° d ONLN d\∞∂º˛ (ÿ‘It doesn’t send ° d ONLN dlº <» • (‰ Zout any packets to tell ° d ONLN dѺ •»˛ )iLthe world it’s still alive while it is printing, so the connection times out ° d ONLN d—» <‘; ( Z7after about 2 minutes. This problem exists in both the ° d ONLN d»;‘˛ )ˇ%1.0 and 2.0 LaserWriter ROMs and will ° d ONLN d.‘ <‡ N (¸ Znot ° d ONLN d1‘ N‡ Ú )" be fixed in the next ROM version. ° d ONLN dTÏ <¯ F ( Z3. ° d ONLN dWÏ N¯¡ )DWhen printing a document that contains more than 10 patterns, users ° d ONLN dõÏ¡¯˛ (fl may receive ° d ONLN d߯ <f ( Z@intermittent PostScript errors. This usually occurs when trying ° d ONLN dÁ¯f· ( Ñ to print a lot of patterns, ° d ONLN d¯·ı ){and ° d ONLN d¯ı˛ ) a ° d ONLN d <| (, Z=bitmap image on the same page. The code for imaging patterns ° d ONLN dF|˛ (,öallocates almost all of the ° d ONLN db < _ (8 Z:available RAM for itself, so when the bitmap imaging code ° d ONLN dú_ ˛ (8}"tries to allocate space, and there ° d ONLN dø <( ï (D Zisn’t enough (and ° d ONLN d— ï(˛ )YEit doesn’t know how to reclaim memory from the previous operation), a ,
Courier ° d ONLN d( <4 Ç (Q Z
limitcheck ° d ONLN d!) Ç5 à )F ° d ONLN d") à5˛ )Eerror occurs. This problem exists in 2.0 LaserWriter ROMs. It will be ° d ONLN dh5 <A ~ (] Z
improved but ° d ONLN du5 ~A ê )Bnot ° d ONLN dx5 êA& ) fixed in the next ROM version. ° d ONLN dòM <Y F (u Z4. ° d ONLN dõM NY≈ )NIf a user chooses US Letter or B5 paper and has a different sized tray in the ° d ONLN dÈM≈Y˛ (u„ printer, and ° d ONLN dˆY <e¿ (Å ZSprints using manual feed, the LaserWriter will print assuming that the paper being ° d ONLN d IY¿e˛ (Åfi fed manually ° d ONLN d Ve <qv (ç ZEis the same size as that in the tray. For example, if they have a US ° d ONLN d õevq˛ (çî letter tray in the LaserWriter ° d ONLN d ∫q <}+ (ô Z3and print a document formatted for B5 letter using ° d ONLN d Ìq+}˛ )Ô+manual feed, the image will not be centered ° d ONLN d
} <â \ (• Zon the ° d ONLN d
} \Ⲡ) Wpage. The printer assumes that the manually fed paper is also US letter size and prints ° d ONLN d
xä <ñ l (≤ Z
the image ° d ONLN d
Çä lñ‚ )0Ppositioned accordingly, despite the driver’s instructions. This is a bug in the ° d ONLN d
“â‚ï˛ (≤ Note ¡ X¡
(÷ Z PR 5 - LaserWriter ROMs Bugs (÷1 ) of 2 (Ï ZM.PR.LaserWriterROMBugs ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø F ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )§ *Roperator in PostScript, which the driver uses for specifying the US letter and B5 ° d ONLN d R § )⁄ ( E¬ letter paper ° d ONLN d _ ) 5 ∂ ( Q 6!sizes. The workaround is to tell ° d ONLN d Ä ) ∂ 5⁄ )û:the user to put an B5 tray in the printer when printing B5 ° d ONLN d ª 5 AL ( ] 6?manually. This problem exists in the 1.0 and 2.0 ROMs and will ° d ONLN d ˙ 5L A^ ( ]jnot ° d ONLN d ˝ 5^ Añ )
be fixed in ° d ONLN d
5ñ A⁄ )8 the next ROM ° d ONLN d A M ? ( i 6version. ° d ONLN d! Y e Ó **By the way, an interesting, but annoying, ° d ONLN dK Y Ó e⁄ )÷+occurance of this bug happens when manually ° d ONLN dw e qq ( ç 6Eprinting Legal sized documents with the 4.0 LaserWriter driver. When ° d ONLN dº eq q⁄ ( çèthe Larger Print Area ° d ONLN d“ r ~ ¸ ( ö 63option in the style dialog is deselected (which is ° d ONLN d r ¸ ~ì )‰!the default) the driver uses the ,
Courier ° d ONLN d& qì }Ø )óNote ° d ONLN d* rØ ~⁄ ) operator ° d ONLN d4 ~ ä ´ ( ¶ 6 to specify the page size. When ° d ONLN dS ~ ´ ä⁄ )ì<the user prints the document using manual feed, and has a US ° d ONLN dê ä ñ ˜ ( ≤ 64letter tray in the printer, the image is shifted up ° d ONLN dƒ ä ˜ ñ⁄ )fl0on the page cutting off the top of the image. If ° d ONLN dı ñ ¢ ( æ 6(you tell the user to turn on the Larger ° d ONLN d ñ ¢⁄ )≤;Print Area option in the style dialog, the driver specifies ° d ONLN dY £ Ø t ( À 6the page size using ° d ONLN dm ¢ t Æ ó )\Legal ° d ONLN dr £ ó Ø À )# instead of ° d ONLN d~ ¢ À Æ Á )4Note ° d ONLN dÇ £ Á Øâ ) # and the image is printed properly. ° d ONLN d¶ ” fl Ç ( ˚ 6Further Reference: ˛ 4 ˛˘ ° d ONLN dπ ‡ * Ï . +
• ° d ONLN dª ‡ < Ï £ )The Printing Manager ° d ONLN d– Ï * ¯ . ( H• ° d ONLN d“ Ï < ¯ ˆ )$PostScript Language Reference Manual ° d ONLN dˆ Ï ˆ ¯G )∫, Adobe Systems ¡ 4¡˘
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ǩ ( ú Z*PR 6 - Using Low-Level Printing Calls With ° d ONLN d + Å < î *AppleTalk ImageWriters
° d ONLN d B ì < ¢ s *Printing
° d ONLN d L Æ < ∫ t * Revised by: ° d ONLN d X Æ Ñ ∫ Û )HScott "ZZ" Zimmerman ° d ONLN d m Æ∏ ∫˛ ( ÷÷
February 1988 ° d ONLN d { ∫ < Δ t ( ‚ Z Revised by: ° d ONLN d à ∫≈ Δ˛ ( ‚„
Courier ° d ONLN dh.'f )ÚabortErr ° d ONLN dp f(j )8. ° d ONLN dr4 <@ ë (\ ZSince there is no ° d ONLN dÑ4 ë@˛ )UGway to tell when you are printing to an AppleTalk ImageWriter, the only ° d ONLN dÃ@ <L{ (h ZDworkaround for this is to use high-level Printing Manager interface. ° d ONLN dp <| ¶ *0Further Reference: õ Xõ ° d ONLN d$} Nâ R +
• ° d ONLN d&} `â « )The Printing Manager ¡ X¡
(÷ ZAPR 6 - Using Low-Level Printing Calls With AppleTalk ImageWriters (÷1 ) of 1 (Ï ZM.PR.ImageWriter ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øí ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç … ( ú ZPR 7 - PrGeneral
° d ONLN d Å < ê s *Printing
° d ONLN d ú < ® t * Revised by: ° d ONLN d ( ú≈ ®˛ ( ƒ„
March 1988 ° d ONLN d 3 ® < ¥ q ( – Z Written by: ° d ONLN d ? ® Ñ ¥ à )HGinger Jenigan ° d ONLN d N ®Œ ¥˛ ( –ÏMay 1987 ° d ONLN d W ¿ < Ãí ( Ë ZAThe Printing Manager architecture has been expanded to include a ° d ONLN d ò ¿í Ã˛ ( Ë∞new procedure called ,
Courier ° d ONLN d ≠ à < ÿ { ( ı Z PrGeneral ° d ONLN d ∂ Õ { Ÿ ø )?. The features ° d ONLN d ≈ Õ ø Ÿ˛ )DBdescribed here are advanced, special-purpose features, intended to ° d ONLN d Ÿ <  ( Z/solve specific problems for those applications ° d ONLN d7 Ÿ ² )‡.that need them. The calls to determine printer ° d ONLN df  < Ò (
Z/resolution introduce a good deal of complexity ° d ONLN dï Â Ò˛ )fi/into the application’s code, and should be used ° d ONLN d≈ Ò < ˝ £ ( Zonly when necessary. ( X( ° d ONLN d⁄ <"ä *%GVersion 2.5 (and later) of the ImageWriter driver and version 4.0 (and ° d ONLN d!ä"˛ (>®later) of the LaserWriter ° d ONLN d;# </ ¿ (K Zdriver implement a generic ° d ONLN dV# ¿/m )Ñ"Printing Manager procedure called ° d ONLN dx"m.¨ )≠ PrGeneral ° d ONLN dÅ#¨/˛ )?. This procedure ° d ONLN dí/ <; ^ (W Zallows ° d ONLN dô/ ^;˛ )"Vthe Print Manager to expand in functionality, by allowing printer drivers to implement ° d ONLN d< <H% (d Z1various new functions. The Pascal declaration of ° d ONLN d!;%Gd )È PrGeneral ° d ONLN d*<dHr )? is:
° d ONLN d0T `_ ({ ~!PROCEDURE PrGeneral (pData: Ptr);
° d ONLN dRk <w Q (ì ZThe ° d ONLN dVj Qv t )pData ° d ONLN d[k twü )#C parameter is a pointer to a data block. The structure of the data ° d ONLN dûküw˛ (ìΩblock is declared as ° d ONLN d≥w <É c (ü Zfollows:
° d ONLN dΩè `ö™ +$BTGnlData = RECORD {1st 8 bytes are common for all PrGeneral calls) ° d ONLN dô `§ *
iOpCode : INTEGER; {input} ° d ONLN d#£ `Æ *
! iError : INTEGER; {output} ° d ONLN dF≠ `∏Z *
2 lReserved : LONGINT; {reserved for future use} ° d ONLN dz∑ `¬_ *
3 {more fields here, depending on particular call} ° d ONLN dØ¡ `à t *
END;
° d ONLN d¥ÿ <‰ ä ( ZThe first field is ° d ONLN d«ÿ ä‰ fl )Na 2-byte opcode, ° d ONLN dÿ◊ fl„ )UiOpCode ° d ONLN dflÿ‰˛ )13, which acts like a routine selector. The currently ° d ONLN d‰ < Ù ( Z&available opcodes are described below. ° d ONLN d:˝ < Q *The ° d ONLN d>˝ Q Í )"second field is the error result, ° d ONLN d`¸ Í )ôiError ° d ONLN df˝ ˛ )*1, which is returned by the print code. This error ° d ONLN dò
< € (2 Z$only reflects error conditions that ° d ONLN dº
€. )üoccur during the ° d ONLN dÕ .m )S PrGeneral ° d ONLN d÷
m˛ )? call. For example, if you use ° d ONLN dı <# (? Z1an opcode that isn’t implemented in a particular ° d ONLN d& #ø )·#printer driver then you will get a ° d ONLN dIø"˛ )¢ OpNotImpl ° d ONLN dS# </ W (K Zerror. ° d ONLN dZ; <G Í *&Here are the errors currently defined:
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øP ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * W *After calling ,
Courier ° d ONLN d W ) ñ )? PrGeneral ° d ONLN d ñ * ‘ )? you should ° d ONLN d # ‘ * )>
always check ° d ONLN d 0 )K )FPrError ° d ONLN d 7 K *a )1. If ° d ONLN d < a )Ñ )noErr ° d ONLN d A Ñ *⁄ )# is returned, then ° d ONLN d T + 7 w ( S 6you can proceed. If ° d ONLN d h * w 6 ƒ )_ ResNotFound ° d ONLN d s + ƒ 7L )M is returned, then the current ° d ONLN d í +L 7⁄ )à printer driver doesn’t support ° d ONLN d ± 7 C W ( ` 6 PrGeneral ° d ONLN d ∫ 8 W D_ )?5 and you should proceed appropriately. See Technical ° d ONLN d Ô 8_ D⁄ ( `}Note #118 for details on ° d ONLN d D P ( l 61checking errors returned by the Printing Manager. ° d ONLN d; \ h B *IError ° d ONLN dA ] B iì )*J is followed by a four byte reserved field (that means don’t use it). The ° d ONLN dã ]ì i⁄ ( Ö±contents of the ° d ONLN dõ i u ∂ ( ë 6"rest of the data block depends on ° d ONLN dΩ i ∂ u⁄ )û>the opcode that the application uses. There are currently five ° d ONLN d¸ u Å- ( ù 68opcodes used by the ImageWriter and LaserWriter drivers.
° d ONLN d5 ô ® m *' The Opcodes
° d ONLN dA µ ¡ ˛ *3Initially, the following calls are implemented via ° d ONLN dt ¥ ˛ ¿= )Ê PrGeneral ° d ONLN d} µ= ¡@ )?: ° d ONLN dÄ Œ < ⁄ F ( ˆ Z• ° d ONLN dÉ Õ F Ÿ å )
GetRslData ° d ONLN dç Œ å ⁄ Û )F (get resolution data): ° d ONLN d• Õ Û Ÿ@ )g iOpCode = 4 ° d ONLN d≤ € < Á F ( Z• ° d ONLN dµ ⁄ F Ê p )
SetRsl ° d ONLN dª € p Á ¿ )* (set resolution): ° d ONLN dŒ ⁄ ¿ Ê
)P iOpCode = 5 ° d ONLN d€ Ë < Ù F ( Z• ° d ONLN dfi Á F Û Ö )
DraftBits ° d ONLN dÁ Ë Ö Ù ˝ )? (bitmaps in draft mode): ° d ONLN d Á ˝ ÛJ )x iOpCode = 6 ° d ONLN d ı < F ( Z• ° d ONLN d Ù F ì )
noDraftBits ° d ONLN d ı ì )M (no bitmaps in draft mode): ° d ONLN d9 Ù g )á iOpCode = 7 ° d ONLN dF < F (* Z• ° d ONLN dI F
w )
GetRotn ° d ONLN dP w Ω )1 (get rotation): ° d ONLN da Ω
)F iOpCode = 8 ° d ONLN dm ' - (C 6The ° d ONLN dq -& s )
GetRslData ° d ONLN d{ s' ä )F and ° d ONLN dÄ ä& ¥ )SetRsl ° d ONLN dÜ ¥'i )*( allow the application to find out what ° d ONLN dÆi'⁄ )µphysical resolutions the ° d ONLN d«( 4 ˚ (P 6/printer supports, and then specify a supported ° d ONLN dˆ( ˚43 )„ resolution. ° d ONLN d'33r )8 DraftBits ° d ONLN d (r4ç )? and ° d ONLN d'ç3⁄ ) noDraftBits ° d ONLN d 5 A < (] 6invoke ° d ONLN d#5 <AÄ )$?a new feature of the ImageWriter, allowing bitmaps (imaged via ° d ONLN db4Ä@∏ (]ûCopyBits ° d ONLN dj5∏A⁄ )8) to be ° d ONLN drB N Ç (j 6printed in draft mode. ° d ONLN dâA ÇM ≥ )jGetRotn ° d ONLN dêB ≥N± )15 lets an application know whether landscape has been ° d ONLN d≈B±N⁄ )˛ selected. ° d ONLN dœN Z. (v 6:Below is a detailed description of how each routine works.
° d ONLN d
r Å † *'The GetRslData Call
° d ONLN d ç ô ^ *
GetRslData ° d ONLN d(é ^ö i )F ( ° d ONLN d*ç iô æ ) iOpCode = 4 ° d ONLN d5é æö† )U-) returns a record that lets the application ° d ONLN dbé†ö⁄ )‚ know what ° d ONLN dlõ ß ≠ (√ 6 resolutions are supported by ° d ONLN dâõ ≠ß∞ )ï2the current printer. The application can then use ° d ONLN dªö∞¶⁄ (√ŒSetRsl ° d ONLN d¬ß ≥ô (œ 6T(description follows) to tell the printer driver which one it will use. This is the ° d ONLN dßô≥⁄ (œ∑
format of the ° d ONLN d$¥ ¿ à (‹ 6input data block for the ° d ONLN d=≥ àø Œ )p
GetRslData ° d ONLN dG¥ Œ¿ ‰ )F call:
° d ONLN dOà <◊ á (Û ZTRslRg = RECORD ° d ONLN d_à ®◊ )l{used in TGetRslBlk} ° d ONLN dv÷ `·U (˝ ~1{0 if printer only supports discrete resolutions} ° d ONLN d™‡ `Î ó *
iMin, iMax: ° d ONLN d∂‡ ®Î – )HInteger; ° d ONLN d¿Í <ı P ( ZEND; ° d ONLN dΔ˛ < å *TRslRec = RECORD ° d ONLN d◊˛ ® )l{used in TGetRslBlk} ° d ONLN dÓ `x (/ ~8iXRsl, iYRsl: Integer; {a discrete, physical resolution} ° d ONLN d( < P (9 ZEND; ° d ONLN d.( <3 õ *TGetRslBlk = RECORD ° d ONLN dB( ®3H )l {data block for GetRslData call} ° d ONLN de2 `= à (Y ~iOpCode: ° d ONLN dn2 ®= – )HInteger; ° d ONLN dw2 =c )H{input; = getRslDataOp} ° d ONLN dë< `G É (c ~iError: ° d ONLN dô< ®G – )HInteger; ° d ONLN d¢< G )H{output} ° d ONLN d≠F `Q í (m ~
lReserved: ° d ONLN d∏F ®Q – )HLongInt; ° d ONLN d¡F Qm )H{reserved for future use} ° d ONLN d›P `[ à (w ~iRgType: ° d ONLN dÊP ®[ – )HInteger; ° d ONLN dÔP [h )H{output; version number} ° d ONLN d
. +Z-Developer Support Center ( -Ê October 1990 / X / ,
Courier
° d ONLN d < ( n ( D Z
depends on ° d ONLN d ' < 2' *
/ ° d ONLN d < '\ 2ù ( Nz
printer type} ° d ONLN d K 1 ` < t ( X ~END;
° d ONLN d P H < T Q ( p ZThe ° d ONLN d T G Q S Ç )iRgType ° d ONLN d [ H Ç T ® )1
field is ° d ONLN d e H ® T˛ )&Hmuch like a version number; it determines the interpretation of the data ° d ONLN d Æ U < a ∂ ( } Zthat follows. At present, ° d ONLN d » U ∂ a ¿ )za ° d ONLN d T ¿ ` Ò )
iRgType ° d ONLN d — U Ò a˛ )16 value of 1 applies both to the LaserWriter and to the ° d ONLN d a < m { ( â Z ImageWriter. ° d ONLN d z < Üü *LFor variable-resolution printers like the LaserWriter, the resolution range ° d ONLN da zü Üæ ( ¢Ωfields ° d ONLN dh yæ ÖË ) XRslRg ° d ONLN dn zË Ü˛ )* and ° d ONLN ds Ü < í f ( Ø ZYRslRg ° d ONLN dy á f ì- )*' express the ranges of values to which ° d ONLN d† á- ì˛ )«'the X and Y resolutions can be set. For ° d ONLN d» ì < ü] ( ª Z>discrete-resolution printers like the ImageWriter, the values ° d ONLN d ì] ü˛ ( ª{"in the resolution range fields are ° d ONLN d) ü < ´ T ( « Zzero. ° d ONLN d/ ∑ < √ [ *Note: ° d ONLN d4 ∑ [ √ ) & In general, X and Y in these records ° d ONLN dZ ∑ √⁄ )±-are the horizontal and vertical directions of ° d ONLN dà √ ` œ q ( Î ~the ° d ONLN då √ q œ ó )printer ° d ONLN dì √ ó œ ˆ )&, not the document! ° d ONLN dß √ ˆ œ⁄ )_0In landscape orientation, X is horizontal on the ° d ONLN dÿ œ ` € ( ˜ ~%printer but vertical on the document. ° d ONLN d˛ Á < Û& ( Z2After the resolution range information there is a ° d ONLN d0 Á& Û˛ )Í)word which gives the number of resolution ° d ONLN dZ Û < ˇ¡ ( ZRrecords that contain information. These records indicate the physical resolutions ° d ONLN d¨ Û¡ ˇ˛ (fl at which the ° d ONLN dπ ˇ < œ (' ZWprinter can actually print dots. Each resolution record gives an X value and a Y value. ° d ONLN d <$ É *When you call ° d ONLN d É# ¬ )G PrGeneral ° d ONLN d( ¬$í )?/ you pass in a data block that looks like this: † Ç † å
O ’'°
4R ÿei 8 ° ñ z ° ö ˇ˛ † ò , Helvetica
ÿ à ÿ à ° d ONLN dˇˇ +õ 1 word † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ (^ fi
OpCode = 4 † ô † ó 4d ÿwi 8 ° ñ z 2izrô ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ z ° ö ˇ˛ , † ò ° d ONLN dˇˇ (p fi
Error Code † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù2 words † ô † ó 4v ÿâi 8 ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ (Ç fiReserved † ô † ó 4à ÿõi 8 ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ (î fi
RangeType = 1 † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù-2 words † ô † ó 4µ ÿ—i 8 ° ñ z ° ö , † ò ° d ONLN dˇˇ (¿ ›Y Resolution Range:
† ô ° ö ˇ˘ , † ò ° d ONLN dˇˇ * min =0, max = 0 † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ +û1 word † ô † ó 4– ÿ„i 8 ° ñ z ° ö ˇ˛ ; † ò ° d ONLN dˇˇ (€ ›Resolution Record Count =0 † ô † ó ° ñ z ° ö ˇ˛ † ò ° d ONLN dˇˇ +û2 words † ô † ó 4‚ ÿ˛i 8 ° ñ z ° ö . † ò ° d ONLN dˇˇ (Ì ›Resolution Record #1:
† ô ° ö ˇ˘ . † ò ° d ONLN dˇˇ * X = 0, Y = 0 † ô † ó 4ö ÿ∂i 8 ° ñ z ° ö , † ò ° d ONLN dˇˇ (£ ›X Resolution Range:
≠ » ≠ » ° d ONLN dˇˇ ( JW1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ ( J ∫
OpCode = 4 † ô † ó † ç † å 4 O ¥ bE 8 ° ñ 2 TV _u ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ ( \ ∫Error Code (0 = okay) † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù2 words † ô † ó 4 a ¥ tE 8 ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ ( n ∫Reserved † ô † ó † ç † å 4 s ¥ ÜE 8 ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ ( Ä ∫
RangeType = 1 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù-2 words † ô † ó 4 † ¥ ºE 8 ° ñ ° ö C † ò ° d ONLN dˇˇ ( ¨ πY Resolution Range:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * min = 72, max = 1500 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û1 word † ô † ó 4 ª ¥ ŒE 8 ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ ( « πResolution Record Count = 1 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û2 words † ô † ó 4 Õ ¥ ÈE 8 ° ñ ° ö C † ò ° d ONLN dˇˇ ( Ÿ πResolution Record #1:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * X = 300, Y = 300 † ô † ó † ç † å 4 Ö ¥ °E 8 ° ñ ° ö C † ò ° d ONLN dˇˇ ( è πX Resolution Range:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * min = 72, max = 1500 † ô † ó ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ ( ïW2 words † ô † ó † ç † ç † É
IR
° d ONLN d ‚ Ó0 (
6<Note that all the resolution range numbers happen to be the ° d ONLN d < ‚0 Ó⁄ (
N$same for this printer. There is only ° d ONLN d a Ó ˙“ ( 6]one resolution record, which gives the physical X and Y resolutions of the printer (300x300). ° d ONLN d ø *5Below is the data block returned for the ImageWriter. † Ç † å † å
= ≥;{ 4> ¥QE 8 ° ñ ° ö ˇ˛ † ò
˛ » ˛ » ° d ONLN dˇˇ (KW1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ (K ∫
OpCode = 4 † ô † ó † ç † å 4P ¥cE 8 ° ñ 2UV`u ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ (] ∫Error Code (0 = okay) † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù2 words † ô † ó 4b ¥uE 8 ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ (o ∫Reserved † ô † ó † ç † å 4t ¥áE 8 ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù1 word † ô † ó ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ (Å ∫
RangeType = 1 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +ù-2 words † ô † ó 4° ¥ΩE 8 ° ñ ° ö C † ò ° d ONLN dˇˇ (≠ πY Resolution Range:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * min = 0, max = 0 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û1 word † ô † ó 4º ¥œE 8 ° ñ ° ö ˇ˛ C † ò ° d ONLN dˇˇ (» πResolution Record Count = 4 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û2 words † ô † ó 4Œ ¥ÍE 8 ° ñ ° ö C † ò ° d ONLN dˇˇ (⁄ πResolution Record #1:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * X = 72, Y = 72 † ô † ó † ç † å 4Ü ¥¢E 8 ° ñ ° ö C † ò ° d ONLN dˇˇ (ê πX Resolution Range:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * min =0, max = 0 † ô † ó ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ (ñW2 words † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ *`2 words † ô † ó 4È ¥E 8 ° ñ ° ö C † ò ° d ONLN dˇˇ (ı πResolution Record #2:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * X =144, Y = 144 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û2 words † ô † ó 4 ¥ E 8 ° ñ ° ö C † ò ° d ONLN dˇˇ ( πResolution Record #3:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * X = 80, Y = 72 † ô † ó † ç † å ° ñ ° ö ˇ˛ † ò ° d ONLN dˇˇ +û2 words † ô † ó 4 ¥;E 8 ° ñ ° ö C † ò ° d ONLN dˇˇ (+ πResolution Record #4:
† ô ° ö ˇ¯ C † ò ° d ONLN dˇˇ * X = 160, Y = 144 † ô † ó † ç † ç † É
IR
° d ONLN d ı4 @ â (\ 6All the resolution range ° d ONLN d4 â@⁄ )qGvalues are zero, because only discrete resolutions can be specified for ° d ONLN dV@ Lµ (h 6[this printer. There are four resolution records giving these discrete physical resolutions. ° d ONLN d≤Y e F *
Note that ,
Courier ° d ONLN dºX Fd å ).
GetRslData ° d ONLN dΔY åeÖ )F6 always returns the same information for a particular ° d ONLN d¸YÖe⁄ )˘printer type—it is ° d ONLN de q * (ç 6not ° d ONLN de *qÖ )I dependent on what the user does or on printer configuration information. ¡ 4¡˘
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d < , £ ( H ZThe SetRsl Call ,
Courier
° d ONLN d 8 < D f *SetRsl ° d ONLN d 9 f E p )* ( ° d ONLN d 8 p D ° )
iOpCode ° d ONLN d 9 ° Ea )1% = 5) is used to specify the desired ° d ONLN d D 9a E˛ )¿ imaging resolution, after using ° d ONLN d d E < Q Ç ( n Z
GetRslData ° d ONLN d n F Ç RÒ )FO to determine a workable pair of values. Below is the format of the data block:
° d ONLN d ø ^ ` i ú ( Ö ~ TSetRslBlk = ° d ONLN d à ^ ® i Δ )HRECORD ° d ONLN d ” ^ à iX )$ {data block for SetRsl call} ° d ONLN d Ú h Ñ s ¨ ( è ¢iOpCode: ° d ONLN d ˚ h à s Ù )HInteger; ° d ONLN d h ss )H{input; = setRslOp} ° d ONLN d r Ñ } ß ( ô ¢iError: ° d ONLN d" r à } Ù )HInteger; ° d ONLN d+ r }< )H{output} ° d ONLN d6 | Ñ á ∂ ( £ ¢
lReserved: ° d ONLN dA | à á Ù )HLongInt; ° d ONLN dJ | áë )H{reserved for future use} ° d ONLN df Ü Ñ ë ß ( ≠ ¢hPrint: ° d ONLN dn Ü Ã ë Ù )HTHPrint; ° d ONLN dw Ü ë◊ )H'{input; handle to a valid print record} ° d ONLN d° ê Ñ õ ¢ ( ∑ ¢iXRsl: ° d ONLN d® ê ® õ – )$Integer; ° d ONLN d± ê õÅ )H {input; desired X resolution} ° d ONLN d— ö Ñ • ¢ ( ¡ ¢iYRsl: ° d ONLN dÿ ö ® • – )$Integer; ° d ONLN d· ö •Å )H {input; desired Y resolution} ° d ONLN d § ` Ø t ( À ~END;
° d ONLN d ∫ < Δ f ( „ ZhPrint ° d ONLN d ª f « · )* should be the handle ° d ONLN d! ª · «˛ ){4of a print record that has previously been passed to ° d ONLN dV « < ” Ç ( Z
PrValidate ° d ONLN d` » Ç ‘^ )F/. If the call executes successfully, the print ° d ONLN dè »^ ‘˛ )‹ record is updated with the new ° d ONLN dÆ ‘ < ‡” ( ¸ ZVresolution; the data block comes back with 0 for the error and is otherwise unchanged. ° d ONLN d Ì < ˘i *?However, if the desired resolution is not supported, the error ° d ONLN dD Ìi ˘ñ (á
is set to ° d ONLN dN Ïñ ¯’ )- noSuchRsl ° d ONLN dW Ì’ ˘˛ )? and the ° d ONLN d` ˘ <F (! Z=resolution fields are set to the printer’s default resolution ° d ONLN dû < : *5Note that you can undo the effect of a previous call ° d ONLN d”: H )˛to ° d ONLN d÷H r )SetRsl ° d ONLN d‹r ˛ )* by making another call that ° d ONLN d˘ <*π (F ZRspecifies an unsupported resolution (such as 0x0), forcing the default resolution.
° d ONLN dLB <Q ∏ *'The DraftBits Call
° d ONLN d_] <i { * DraftBits ° d ONLN dh^ {j É )? ( ° d ONLN dj] Éi ¥ )iOpCode ° d ONLN dq^ ¥jF )1 = 6) is implemented on both ° d ONLN dé^Fj˛ )í$the ImageWriter and the LaserWriter. ° d ONLN d≥j <v (í Z%(On the LaserWriter it does nothing, ° d ONLN dÿj v˛ )¥5since the LaserWriter is always in draft mode and can ° d ONLN dv <ÇZ (û Z=always print bitmaps.) Below is the format of the data block:
° d ONLN dMé `ô ° +$
TDftBitsBlk = ° d ONLN d[é ®ô Δ )HRECORD ° d ONLN dbé Ãôº )$0{data block for DraftBits and NoDraftBits calls} ° d ONLN dïò Ñ£ ¨ (ø ¢iOpCode: ° d ONLN dûò ã Ù )HInteger; ° d ONLN dßò£◊ )H'{input; = draftBitsOp or noDraftBitsOp} ° d ONLN d—¢ Ñ≠ ß (… ¢iError: ° d ONLN dŸ¢ Ã≠ Ù )HInteger; ° d ONLN d‚¢≠< )H{output} ° d ONLN d̨ Ñ∑ ∂ (” ¢
lReserved: ° d ONLN d¯¨ Ã∑ Ù )HLongInt; ° d ONLN d¨∑ë )H{reserved for future use} ° d ONLN d ∂ Ñ¡ ß (› ¢hPrint: ° d ONLN d%∂ á Ù )HTHPrint; ° d ONLN d.∂¡◊ )H'{input; handle to a valid print record} ° d ONLN dW¿ `À t (Á ~END;
° d ONLN d\÷ <‚ f (ˇ ZhPrint ° d ONLN db◊ f„ · )* should be the handle ° d ONLN dx◊ ·„˛ ){4of a print record that has previously been passed to ° d ONLN d≠„ <Ô Ç ( Z
PrValidate ° d ONLN d∑‰ Ç Ü )F. ° d ONLN dπ¸ < ($ Z.This call forces draft-mode (i.e., immediate) ° d ONLN dÁ¸˛ )‘2printing, and will allow bitmaps to be printed via ° d ONLN d < t (1 ZCopyBits ° d ONLN d" tÈ )8R calls. The virtue of this is that you avoid spooling large masses of bitmap data ° d ONLN dt È˛ (1onto ° d ONLN dy <! (= Z.the disk, and you also get better performance. ° d ONLN d®- <9 ÷ *!The following restrictions apply: ° d ONLN d E NQ R +• ° d ONLN dÃE [Qª )
IThis call should be made before bringing up the print dialogs because it ° d ONLN dEªQ⁄ (mŸaffects ° d ONLN d R [^ Œ (z ytheir appearance. On ° d ONLN d2R Œ^U )sthe ImageWriter, calling ° d ONLN dKQU]î )á DraftBits ° d ONLN dTRî^⁄ )?
disables the ° d ONLN db^ [jg (Ü y;landscape icon in the Style dialog, and the Best, Faster, ° d ONLN dù^gj⁄ (ÜÖand Draft buttons in the ° d ONLN d∂j [v ê (í y Job dialog. ° d ONLN d¬Ç Né R (™ l• ° d ONLN dƒÇ [é Î )
If the printer does not support ° d ONLN d‰Ç Îé⁄ )ê1draft mode, already prints bitmaps in draft mode, ° d ONLN d é [ö\ (∂ y:or does not print bitmaps at all, this call does nothing. ¡ X¡
%Only text and bitmaps can be printed. ° d ONLN d ( A * M . ( i H• ° d ONLN d * A 7 M[ )
=As in the normal draft mode, landscape format is not allowed. ° d ONLN d h Y * e . ( Å H• ° d ONLN d j Y 7 e> )
7Everything on the page must be strictly Y-sorted, i.e. ° d ONLN d ° Y> e∂ ( Å\no reverse paper motion ° d ONLN d π e 7 q ì ( ç Ubetween one string ° d ONLN d à e ì q∂ )\;or bitmap and the next. Note that this means you can’t have ° d ONLN d q 7 } [ ( ô Utwo or ° d ONLN d q [ }∂ )$Emore objects (text or bitmaps) side by side; the top boundary of each ° d ONLN dU } 7 âi ( • UAobject must be no higher than the bottom of the preceding object. ° d ONLN dó ï ° ± ( Ω 6#The last restriction is important. ° d ONLN d∫ ï ± °⁄ )ôBIf you violate it, you will not like the results. But note that if ° d ONLN d˝ ° ≠ … ( … 6"you want two or more bitmaps side ° d ONLN d ° … ≠⁄ )±5by side, you can combine them into one before calling ,
Courier ° d ONLN dU ≠ π P ( ÷ 6CopyBits ° d ONLN d] Æ P ∫ S )8 ° d ONLN d^ Æ S ∫⁄ )Tto print the result. Similarly, if you are just printing bitmaps you can rotate them ° d ONLN d≥ ∫ Δ Œ ( ‚ 6'yourself to achieve landscape printing.
° d ONLN d€ fi Ì ß *'The NoDraftBits Call
° d ONLN d ˘ e * NoDraftBits ° d ONLN d˚ ˙ e l )M ( ° d ONLN d˝ ˘ l ù )iOpCode ° d ONLN d ˙ ùw )1- = 7) is implemented on both the ImageWriter ° d ONLN d1 ˙w⁄ )⁄and the LaserWriter. ° d ONLN dF à (. 6%(On the LaserWriter it does nothing, ° d ONLN dk Ã⁄ )¥5since the LaserWriter is always in draft mode and can ° d ONLN d° P (; 6@always print bitmaps.) The format of the data block is the same ° d ONLN d·P õ (;nas that for the ° d ONLN dÒõ ⁄ )K DraftBits ° d ONLN d˚ + , (G 6call. ° d ONLN d8 D ¯ *.This call cancels the effect of any preceding ° d ONLN d/7 ¯C7 )‡ DraftBits ° d ONLN d887D< )? ° d ONLN d98<D⁄ ) call. If there was no preceding ° d ONLN dYD P W (m 6 DraftBits ° d ONLN dbE WQô )?C call, or the printer does not support draft-mode printing anyway, ° d ONLN d•EôQ⁄ (m∑this call does ° d ONLN d¥Q ] @ (y 6nothing.
TGetRotnBlk = ° d ONLN dLµ Ñ¿ ¢ )HRECORD ° d ONLN dSµ ®¿9 )$ {data block for GetRotn call} ° d ONLN dsø ` à (Ê ~iOpCode: ° d ONLN d|ø ® – )HInteger; ° d ONLN dÖø T )H{input; = getRotnOp} ° d ONLN dú… `‘ É ( ~iError: ° d ONLN d§… ®‘ – )HInteger; ° d ONLN d≠… ‘ )H{output} ° d ONLN d∏” `fi í (˙ ~
lReserved: ° d ONLN d√” ®fi – )HLongInt; ° d ONLN dÔ fim )H{reserved for future use} ° d ONLN dË› `Ë É ( ~hPrint: ° d ONLN d› ®Ë – )HTHPrint; ° d ONLN d˘› Ë≥ )H'{input; handle to a valid print record} ° d ONLN d#Á `Ú ó ( ~ fLandscape: ° d ONLN d/Á ®Ú – )HBoolean; ° d ONLN d8Á Ú^ )H{output; Boolean flag} ° d ONLN dQÒ `¸ ~ ( ~bXtra: ° d ONLN dXÒ Ñ¸ ª )$ SignedByte; ° d ONLN deÒ ¸" )l
{reserved} ° d ONLN dq˚ < P (" ZEND;
° d ONLN dv B (: 6hPrint ° d ONLN d| B ó )* should be the ° d ONLN dã ó ⁄ )U;handle to a print record that has previously been passed to ° d ONLN d« * ^ (G 6
PrValidate ° d ONLN d— ^+ b )F. ° d ONLN d”8 D. (` 6?If landscape orientation is selected in the print record, then ° d ONLN d7.Ct (`L
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d < ,0 ( H Z How To Use The PrGeneral Opcodes
° d ONLN d ! 9 < E Q *The ,
Courier ° d ONLN d % 8 Q D { )SetRsl ° d ONLN d + 9 { E í )* and ° d ONLN d 0 8 í D — ) DraftBits ° d ONLN d 9 9 — E ‘ )? ° d ONLN d : 9 ‘ E˛ )?calls may require the print code to suppress certain options in ° d ONLN d z E < Qû ( m ZLthe Style and/or Job dialogs, therefore they should always be called before ° d ONLN d Δ Eû Q˛ ( mºany call to the Style ° d ONLN d ‹ Q < ]e ( y Z@or Job dialogs. An application might use these calls as follows: ° d ONLN d j N v R +• ° d ONLN d j [ v ˘ )
"Get a new print record by calling ° d ONLN dA i ˘ uM )û PrintDefault ° d ONLN dM jM vÖ )T
, or take an ° d ONLN dZ jÖ v⁄ )8existing one from ° d ONLN dl w [ É ª ( ü ya document and call ° d ONLN dÄ v ª Ç )`
PrValidate ° d ONLN dä w É )F on it. ° d ONLN dí ê N ú R ( ∏ l• ° d ONLN dî ê [ ú r )
Call ° d ONLN d÷ Œ q ⁄ õ )SetRsl ° d ONLN d‹ œ õ €∑ )*> with the print record and the desired resolution if you wish. ° d ONLN d Ë N Ù R ( l• ° d ONLN d Ë [ Ù q )
Call ° d ONLN d" Á q Û ∞ ) DraftBits ° d ONLN d+ Ë ∞ ÙÃ )?= to invoke the printing of bitmaps in draft mode if you wish. ° d ONLN di <
ø () Z Note that if you call either ° d ONLN dÜ ø È )ÉSetRsl ° d ONLN då È
˚ )* or ° d ONLN dê ˚ : ) DraftBits ° d ONLN dô:
õ )?, you should do so ° d ONLN d¨õ
˛ )abefore the user sees ° d ONLN d¡
< ≈ (5 Z either of the printing dialogs. ° d ONLN d·= <I ¶ *0Further Reference: h Xh ° d ONLN dÙJ NV R +
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å ( õ ZPR 8 - PrGeneral Bug
° d ONLN d Ä < è s *Printing
° d ONLN d õ < ß t * Revised by: ° d ONLN d , õ≈ ߲ ( √„
March 1988 ° d ONLN d 7 ß < ≥ q ( œ Z Written by: ° d ONLN d C ß Ñ ≥ Û )HScott "ZZ" Zimmerman ° d ONLN d X ß± ≥˛ ( œœ
November 1987 ° d ONLN d f ø < À‚ ( Á ZUThis technical note documents a bug in the implementation of the PrGeneral procedure ° d ONLN d ª ø‚ À˛ ( Á in the ° d ONLN d ¬ À < ◊ ˝ ( Û Z(LaserWriter driver version 4.0. The bug ° d ONLN d Í À ˝ ◊˛ )¡5has to do with the format of the information returned ° d ONLN d ◊ < „F ( ˇ Z3by the GetRslData opcode. This technical note will ° d ONLN dS ◊F „˛ ( ˇd"also describe a workaround for the ° d ONLN dv „ < Ô g ( Zproblem. X ° d ONLN d < € *& One of the opcodes supported by ° d ONLN dü € Ì )üthe ,
Courier ° d ONLN d£ Ì, ) PrGeneral ° d ONLN d¨ ,˛ )?) procedure (Technical Note #128) is named ° d ONLN d÷ <! Ç (> Z
GetRslData ° d ONLN d‡ Ç" § )F. The ° d ONLN dÊ §! Í )"
GetRslData ° d ONLN d Í"∏ )F+ operation initializes a resolution record ° d ONLN d∏"˛ )Œthat is of the ° d ONLN d*" <. á (J Zfollowing form:
° d ONLN d;: `E +$$TRslRg = RECORD {used in TGetRslBlk} ° d ONLN dbD ÑO ù +$
iMin: ° d ONLN dhD ®O – )$Integer; ° d ONLN dqD OÂ )H1{0 if printer only supports discrete resolutions} ° d ONLN d•N ÑY ù (u ¢iMax: ° d ONLN d´N ®Y – )$Integer; ° d ONLN d¥N Y§ )H${0 if printer only supports discrete ° d ONLN d⁄X <c1 ( Z1 resolutions} ° d ONLN d
b `m t +$
END; ° d ONLN dv `Å ∞ *TRslRec = RECORD ° d ONLN d+v ÃÅ0 )l{used in TGetRslBlk} ° d ONLN dBÄ Ñã ¢ (ß ¢iXRsl: ° d ONLN dIÄ ®ã – )$Integer; ° d ONLN dRÄ ãü )H#{a discrete, physical X resolution} ° d ONLN dxä Ñï ¢ (± ¢iYRsl: ° d ONLN dä ®ï – )$Integer; ° d ONLN dàä ïü )H#{a discrete, physical Y resolution} ° d ONLN d≠î `ü t (ª ~END; ° d ONLN dµ® `≥d *4TGetRslBlk = RECORD {data block for GetRslData call} ° d ONLN dÏ≤ ÑΩ ¨ +$
iOpCode: ° d ONLN dı≤ ÃΩ Ù )HInteger; ° d ONLN d˛≤Ωá )H{input; = getRslDataOp} ° d ONLN dº Ñ« ¨ („ ¢iError: ° d ONLN d!º ë Ù )HInteger; ° d ONLN d*º«< )H{output} ° d ONLN d5Δ Ñ— ∂ (Ì ¢
lReserved: ° d ONLN d@Δ Ã— Ù )HLongInt; ° d ONLN dIΔ—ë )H{reserved for future use} ° d ONLN de– Ñ€ ¨ (˜ ¢iRgType: ° d ONLN dn– À Ù )HInteger; ° d ONLN dw–€· )H){output; this declaration is for RgType1} ° d ONLN d£⁄ Ñ ¨ ( ¢XRslRg: ° d ONLN d¨⁄ à٠)HTRslRg; ° d ONLN dµ⁄Â¥ )H {output; range of X resolutions} ° d ONLN dÿ‰ ÑÔ ¨ ( ¢YRslRg: ° d ONLN d·‰ ÃÔ Ù )HTRslRg; ° d ONLN d͉ԥ )H {output; range of Y resolutions} ° d ONLN d
Ó Ñ˘ Ë ( ¢iRslRecCnt: Integer; ° d ONLN d"Ó ˘ï )l!{output; how many RslRecs follow} ° d ONLN dF¯ Ñ ± ( ¢ rgRslRec: ° d ONLN dP¯ à )H ARRAY[1..27] ° d ONLN db Ã
È *
9OF TRslRec; {output; number used depends on printer type} ° d ONLN dù ` t (3 ~END;
° d ONLN d¢# </ (K Z)The LaserWriter 4.0 implementation has a ° d ONLN dÀ#/e )…bug that affects the ° d ONLN d‡"e.è )`YRslRg ° d ONLN dÊ#è/® )* and ° d ONLN dÎ"®.“ )XRslRg ° d ONLN dÒ#“/˛ )*
fields of ° d ONLN d¸0 << M (X Zthe ° d ONLN d / M; ì )
TGetRslBlk ° d ONLN d
0 ì<d )F/ record. The correct values for the fields are:
° d ONLN d<H ÑS (o ¢ TGetRslBlk.XRslRg.iMin := 25; ° d ONLN d\R Ñ] *
TGetRslBlk.XRslRg.iMax := 1500; ° d ONLN d~\ Ñg *
TGetRslBlk.YRslRg.iMin := 25; ° d ONLN dûf Ñq *
TGetRslBlk.YRslRg.iMax := 1500;
° d ONLN dæ} <âõ (• ZJUnfortunately, the information returned by the LaserWriter 4.0 version of ° d ONLN d|õà⁄ (•π PrGeneral ° d ONLN d}⁄âË )? is: ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø 6 ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ` ( Ò +H TGetRslBlk.XRslRg.iMin := 25; ° d ONLN d ' ` 2 ˆ *
TGetRslBlk.XRslRg.iMax := 25; ° d ONLN d A 1 ` < ˚ *
TGetRslBlk.YRslRg.iMin := 1500; ° d ONLN d c ; ` F ˚ *
TGetRslBlk.YRslRg.iMax := 1500;
° d ONLN d É R ^C ( z 6:The recommended workaround for this problem is to use the ° d ONLN d Ω QC ]â ( za
PrDrvrVers ° d ONLN d « Râ ^ç )F ° d ONLN d » Rç ^Ω )
function ( ° d ONLN d “ RΩ ^⁄ )0Inside ° d ONLN d Ÿ ^ j I ( Ü 6 Macintosh ° d ONLN d ‚ ^ I j" )10 II-163) to find out which version of the print ° d ONLN d ^" j⁄ )Ÿ&driver you are using. If you are using ° d ONLN d9 j v ≤ ( í 6 4.0, modify the resolution data ° d ONLN dY j ≤ v⁄ )ö=before using it. The following code fragment illustrates this ° d ONLN dó v Ç U ( û 6 workaround:
° d ONLN d§ é < ôO +$7PROCEDURE CheckRslRecord(VAR theRslRecord: TGetRslBlk); ° d ONLN d› ò < £ U *
CONST ° d ONLN d ¢ ` ≠ µ +$
BogusDriver = 40; ° d ONLN d¯ ¨ < ∑ U ( ” ZBEGIN ° d ONLN d ∂ ` ¡ +$
&IF PrDrvrVers = BogusDriver THEN BEGIN ° d ONLN d* ¿ Ñ Àç +$
5theRslRecord.XRslRg.iMax := theRslRecord.YRslRg.iMax; ° d ONLN dc Ñ ’ç *
5theRslRecord.YRslRg.iMin := theRslRecord.XRslRg.iMin; ° d ONLN dõ ‘ ` fl t ( ˚ ~END; ° d ONLN d£ fi < È P ( ZEND;
° d ONLN d® ı ( 69When the bug is fixed in a future version of the driver, ° d ONLN d· ı / ( ;the ° d ONLN d Ù/ ë )CheckRslRecord ° d ONLN dÛ ıë⁄ )b procedure will ° d ONLN d
« () 6Yno longer have any effect on the resolution record. This will make sure your application ° d ONLN d\«
⁄ ()Âgets ° d ONLN da
à (5 6Pthe correct resolution data no matter which version of the driver is being used. ° d ONLN d≤= I Ç *0Further Reference: h 4h˘ ° d ONLN d≈J *V . +
• ° d ONLN d«J <V î )The Print Manager ° d ONLN dŸV *b . (~ H• ° d ONLN d€V <b ‚ ) Technical Note M.IM.PrGeneral— ° d ONLN d¸b `n ê +$ PrGeneral ¡ 4¡˘
(÷ 62 ) of 2 (÷†PR 8 - PrGeneral Bug +M.PR.PrGeneralBug ˇ@ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç_ ( ú Z"PR 9 - Print Dialogs: Adding Items
° d ONLN d # Å < ê s *Printing
° d ONLN d - ú < ® t * Revised by: ° d ONLN d : ú≈ ®˛ ( ƒ„
March 1988 ° d ONLN d E ® < ¥ q ( – Z Written by: ° d ONLN d Q ® Ñ ¥ – )HGinger Jernigan ° d ONLN d a ®± ¥˛ ( –œ
November 1986 ° d ONLN d q ¥ Ñ ¿ æ ( ‹ ¢ Lew Rollins ° d ONLN d ~ à < ÿÌ ( Ù ZZThis technical note discusses how to add your own items to the Printing Manager’s dialogs. X ° d ONLN d Ÿ Ò < ˝… *%SWhen the Printing Manager was initially designed, great care was taken to make the ° d ONLN d, Ò… ˝˛ (Á interface to ° d ONLN d9 ˝ < ª (% ZSthe printer drivers as generic as possible in order to allow applications to print ° d ONLN då ˝ª ˛ (%Ÿ
without being ° d ONLN dö <f (1 Z=device-specific. There are times, however, when this type of ° d ONLN d◊ f˛ (1Ñ!non-specific interface interferes ° d ONLN d˘ <! ï (= Zwith the flexibility ° d ONLN d ï!˛ )YKof an application. An application may require additional information before ° d ONLN dZ! <-û (I ZFprinting which is not part of the general Printing Manager interface. ° d ONLN d†!û-˛ (IºThis technical note ° d ONLN d¥- <9Ö (U ZGdescribes a method that an application can use to add its own items to ° d ONLN d˚-Ö9˛ (U£the existing style and job ° d ONLN d9 <E b (a Zdialogs. ° d ONLN d Q <]( *0Before continuing, you need to be aware of some ° d ONLN dOQ(]˛ )Ï-guidelines that will increase your chances of ° d ONLN d}] <iU (Ö Z>being compatible with the printing architecture in the future: ° d ONLN dºu NÅ R +• ° d ONLN dæu [Å )
Do not change the ° d ONLN d]ô ≥•⁄ )X=position of any item in the current dialogs. This means don’t ° d ONLN dõ• [± ≤ (Õ ydelete items from ° d ONLN d≠• ≤±⁄ )W<the existing item list or add items in the middle. Add items ° d ONLN dͱ [Ω Ø (Ÿ yonly at the end ° d ONLN d˘± ØΩ ‚ )T
of the list. ° d ONLN d… N’ R (Ò l• ° d ONLN d … [’Q )
6Don’t count on an item retaining its current position ° d ONLN d?…Q’⁄ )ˆ in the list. If you depend on ° d ONLN d]’ [· ¸ (˝ y$the Draft button being a particular ° d ONLN dÅ’ ¸·⁄ )°-number in the ImageWriter’s style dialog item ° d ONLN dØ· [̃ ( yDlist, and we change the Draft button’s item number for some reason, ° d ONLN dÛ·ƒÌ⁄ ( ‚your ° d ONLN d¯Ì [˘$ ( y)program may no longer function correctly. ° d ONLN d" N R (- l• ° d ONLN d$ [ Í )
Don’t use more than half the ° d ONLN dA Í⁄ )è0screen height for your items. Apple reserves the ° d ONLN dr [ í (9 yDright to expand the items in the standard print dialogs to fill the ° d ONLN d∂í ⁄ (9∞top half of the ° d ONLN dΔ [) } (E yscreen. ° d ONLN dŒ5 NA R (] l• ° d ONLN d–5 [A )
'If you are adding lots of items to the ° d ONLN d˜5A⁄ )∑&dialogs (which may confuse users), you ° d ONLN d A [M Ì (i y should consider having your ° d ONLN d:A ÌM⁄ )í/own separate dialog in addition to the existing ° d ONLN djM [Y ÷ (u yPrinting Manager dialogs. ¡ X¡
(÷ Z"PR 9 - Print Dialogs: Adding Items (÷ˇ1 ) of 13 (Ï Z M.PR.PrintDialogsAddingItems ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øå ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d , Z * The Heart
° d ONLN d
8 D ï *Before we talk about how ° d ONLN d # 8 ï D⁄ )}Dthe dialogs work, you need to know this: at the heart of the printer ° d ONLN d h D P~ ( l 6Ndialogs is a little-known data structure partially documented in the MacPrint ° d ONLN d ∂ D~ P⁄ ( lúinterface file. It’s a ° d ONLN d Õ Q ] W ( y 6record called ,
Courier ° d ONLN d € P W \ Å )?TPrDlg ° d ONLN d · Q Å ] Ê )* and it looks like this:
° d ONLN d ˚ i < tc ( ê Z;TPrDlg = RECORD {Print Dialog: The Dialog Stream object.} ° d ONLN d8 s < ~" *
. dlg : DialogRecord; {dialog window} ° d ONLN dh } < à *
- pFltrProc : ProcPtr; {filter proc.} ° d ONLN dó á < íJ *
B iNumFst : INTEGER; {numeric edit items for std filter} ° d ONLN d · < Ï Ø *
iNumLst : INTEGER; ° d ONLN d% Î < ˆw *
?{... plus more stuff needed by the particular printing dialog.} ° d ONLN df ı < P *
END; ° d ONLN dl ˇ <
, *
0TPPrDlg = ^TPrDlg; {== a dialog ptr}
° d ONLN dù "L (> 6CAll of the information pertaining to a print dialog is kept in the ° d ONLN d‡L!v (>jTPrDlg ° d ONLN dÊv"⁄ )* record. This record ° d ONLN d˚" . (J 67will be referred to frequently in the discussion below.
° d ONLN d3F U Ø *'How the Dialogs Work
° d ONLN dHb n ¢ * When your application calls ° d ONLN dda ¢m Ô )ä PrStlDialog ° d ONLN dob Ôn )M and ° d ONLN dtamU ) PrJobDialog ° d ONLN dbUn⁄ )M , the printer driver actually ° d ONLN dùo { z (ó 6calls a routine called ° d ONLN d¥n zz π )b PrDlgMain ° d ONLN dΩo π{k )?'. This function is declared as follows:
° d ONLN d(û ™ W (« 6 PrDlgMain ° d ONLN d1ü W´ ô )? first calls the ° d ONLN dBû ô™ — )BpDlgInit ° d ONLN dJü —´ú )8. routine to set up the appropriate dialog (in ° d ONLN dxûú™± )ÀDlg ° d ONLN d{ü±´⁄ ) ), dialog ° d ONLN dÖ¨ ∏ 3 (‘ 6hook ° d ONLN dä´ 3∑ Ä ) (pItemProc) ° d ONLN dï¨ Ä∏ Ï )M and dialog event filter ° d ONLN dÆ´ Ï∑G )l
(pFilterProc) ° d ONLN dª¨G∏g )[ in the ° d ONLN d√´g∑ë ) TPrDlg ° d ONLN d…¨ë∏î )* ° d ONLN d ¨î∏⁄ )
record (shown ° d ONLN dÿπ ≈ ü (· 6 above). For the job dialog, ° d ONLN dÙπ ü≈ Í )áthe address of ° d ONLN d∏ ̓) )K PrJobInit ° d ONLN d π)≈n )? is passed to ° d ONLN d∏nƒ≠ )E PrDlgMain ° d ONLN d#π≠≈⁄ )? . For the ° d ONLN d-Δ “ ö (Ó 6 style dialog, the address of ° d ONLN dJ≈ ö— Ÿ )Ç PrStlInit ° d ONLN dSΔ Ÿ“≈ )?3 is passed. These routines are declared as follows:
° d ONLN dàfi <È" ( Z.FUNCTION PrJobInit (hPrint: THPrint): TPPrDlg; ° d ONLN d∏Ë <Û" *
.FUNCTION PrStlInit (hPrint: THPrint): TPPrDlg;
° d ONLN dÁˇ ‡ (' 6-After the initialization routine sets up the ° d ONLN d˛ ‡
)»TPrDlg ° d ONLN dˇ
6 )* record, ° d ONLN d#˛6
u ), PrDlgMain ° d ONLN d,ˇu î )? calls ° d ONLN d3˛î
⁄ )
ShowWindow ° d ONLN d> ‚ (4 6-(the window is initially invisible), then it ° d ONLN dk ‚ ¸ ) calls ° d ONLN dq ¸I ) ModalDialog ° d ONLN d| I⁄ )M , using the dialog event filter ° d ONLN dú % r (A 6pointed to by the ° d ONLN dÆ r$ ± )Z pFltrProc ° d ONLN d∑ ±%⁄ )?: field. When an item is hit, the routine pointed to by the ° d ONLN dÚ% 1 W (N 6 pItemProc ° d ONLN d˚& W2y )?? field is called and the items are handled appropriately. When ° d ONLN d:&y2⁄ (Nóthe OK button is hit ° d ONLN dO2 >) (Z 6:(this includes pressing Return or Enter) the print record ° d ONLN dâ2)>⁄ (ZG%is validated. The print record is not ° d ONLN dØ> J ø (f 6&validated if the Cancel button is hit.
° d ONLN d÷b q ⁄ *'How to Add Your Own Items
° d ONLN d~ ä *4To modify the print dialogs, you need to change the ° d ONLN d $}â9 )˜TPrDlg ° d ONLN d *~9äè )* record before the ° d ONLN d =~èä⁄ )Vdialog is drawn ° d ONLN d Mä ñ (≤ 61on the screen. You can add your own items to the ° d ONLN d ~äñ⁄ (≤9'item list, replace the addresses of the ¡ 4¡˘
° d ONLN d < ) “ ( E Z standard dialog hook and event ° d ONLN d “ )˛ )ñ?filter with the addresses of your own routines and then let the ° d ONLN d _ ) < 5 Ù ( Q Z&dialog code continue on its merry way. ,
Courier ° d ONLN d á A < M f *TPrDlg ° d ONLN d ç B f N$ )*( record for you and return a pointer to ° d ONLN d µ B$ Nì )æthat record. Then call ° d ONLN d à Aì M“ )o PrDlgMain ° d ONLN d ’ B“ N˛ )?
directly, ° d ONLN d ‡ N < Z É ( v Zpassing in the ° d ONLN d Ô N É Z˛ )GNaddress of your own initialization function. The example code’s initialization ° d ONLN d> Z < f› ( Ç Z[function adds items to the dialog item list, saves the address of the standard dialog hook ° d ONLN dô Z› f˛ ( Ç˚(in our ° d ONLN d° g < s Ñ ( è Zglobal variable ° d ONLN d± f Ñ r — )H prPItemProc ° d ONLN dº g — s{ )M%) and puts the address of our dialog ° d ONLN d· g{ sø )™hook into the ° d ONLN dÔ fø r˛ )D pItemProc ° d ONLN d˘ t < Ä u ( ú Z
field of the ° d ONLN d s u ü )9TPrDlg ° d ONLN d t ü Äo )*+ record. Please note that your dialog hook ° d ONLN d7 to Ää )–must ° d ONLN d; tä Ä¥ )
call the ° d ONLN dE t¥ IJ )*standard dialog ° d ONLN dU Ä < å" ( ® Z2hook to handle all of the standard dialog’s items. ° d ONLN dà ò < § [ *Note: ° d ONLN dç ò [ § À ) If you wish to have an ° d ONLN d• ò À §⁄ )p9event filter, handle it the same way that you do a dialog ° d ONLN dfl § ` ∞ | ( à ~hook. ° d ONLN d º < »~ ( ‰ ZBNow, here is an example (written in MPW Pascal) that modifies the ° d ONLN d' º~ »˛ ( ‰újob dialog. The same code ° d ONLN dA » < ‘ ò ( Zworks for the style ° d ONLN dU » ò ‘˛ )\Ldialog if you globally replace ‘Job’ with ‘Stl’. Also included is a function ° d ONLN d¢ ’ < · @ ( ˝ Z( ° d ONLN d£ ‘ @ ‡ Ü )
AppendDITL ° d ONLN d≠ ’ Ü · )F) provided by Lew Rollins ° d ONLN d« ’ ·˛ )Ä7(originally written in C, translated for this technical ° d ONLN dˇ · < ÌH ( Z3note to MPW Pascal) which demonstrates a method of ° d ONLN d2 ·H Ì˛ ( f&adding items to the item list, placing ° d ONLN dY Ì < ˘° ( ZJthem in an appropriate place, and expanding the dialog window’s rectangle.
° d ONLN d§ < ) *' The MPW Pascal Example Program
° d ONLN d√, <7 ™ *PROGRAM ModifyDialogs; ° d ONLN d€@ `K t +$USES ° d ONLN d‚J ÑU Ë +$
{$LOAD PasDump.dump} ° d ONLN d˘T Ñ_ç *
5MemTypes,QuickDraw,OSIntf,ToolIntf,PackIntf,MacPrint; ° d ONLN d0h `s y (è ~CONST ° d ONLN d8r Ñ} ¢ +$
MyDITL ° d ONLN d@r Ã} Ô )H = 256; ° d ONLN dJ| Ñá fi (£ ¢MyDFirstBox = 1; ° d ONLN d^|á√ )ê# {Item number of first box in DITL} ° d ONLN dÑÜ Ñë Ÿ (≠ ¢MyDSecondBox = 2; ° d ONLN dóö `• o (¡ ~VAR ° d ONLN dù§ ÑØ Ú +$
PrtJobDialog: TPPrDlg; ° d ONLN d¥§Øë )ê{ pointer to job dialog } ° d ONLN d–Æ Ñπ ± (’ ¢ hPrintRec ° d ONLN d⁄Æ Ãπ ˛ )H
: THPrint; ° d ONLN dÂÆπñ )H{ Handle to print record } ° d ONLN d∏ Ñ√ œ (fl ¢FirstBoxValue, ° d ONLN d∏√π )ê!{ value of first additional box } ° d ONLN d7¬ ÑÕ (È ¢SecondBoxValue: Integer; ° d ONLN dQ¬Õ™ )ê { value of second addtl. box } ° d ONLN drà Ñ◊ ¿ (Û ¢ prFirstItem, ° d ONLN dÅÃ◊† )ê { save our first item here } ° d ONLN d†÷ Ñ· Ú (˝ ¢prPItemProc : LongInt; ° d ONLN d∑÷·√ )ê#{ need to store old itemProc here } ° d ONLN d›‡ ÑÎ ± ( ¢ itemType ° d ONLN dÁ‡ ÃÎ ˛ )H
: Integer; ° d ONLN dڇλ )H${ need for GetDItem/SetDItem calls } ° d ONLN dÍ Ñı ¢ ( ¢itemH ° d ONLN d!Í Ãı ˘ )H : Handle; ° d ONLN d-Ù Ñˇ ß ( ¢itemBox ° d ONLN d6Ù ˇ )l: Rect; ° d ONLN d@˛ Ñ ì (% ¢err ° d ONLN dF˛ )l: OSErr; ° d ONLN dO <Æ (/ ZJ{------------------------------------------------------------------------} ° d ONLN dõ `' ƒ +$PROCEDURE _DataInit; ° d ONLN d≤& Ñ1 ± +$
EXTERNAL; ° d ONLN dº: <EÆ (a ZJ{------------------------------------------------------------------------} ° d ONLN dN `Y• +$APROCEDURE CallItemHandler(theDialog: DialogPtr; theItem: Integer; ° d ONLN dOX cJ +ê
theProc: LongInt); ° d ONLN ddb Ñm ¿ (â ¢ INLINE $205F ° d ONLN dsbmn )ê{ MOVE.L (A7)+,A0} ° d ONLN dàl Ñw ß (ì ¢,$4E90; ° d ONLN dílwP )ê { JSR (A0) } ° d ONLN düÄ <ãö (ß ZF{ this code pops off theProc and then does a JSR to it, which puts the ° d ONLN dÊä <ï *
° d ONLN d ' 2ä *!J{------------------------------------------------------------------------} ° d ONLN d L ; < Fü +$GFUNCTION AppendDITL(theDialog: DialogPtr; theDITLID: Integer): Integer; ° d ONLN d ï E < Pã *
C{ version 0.1 9/11/86 Lew Rollins of Human-Systems Interface Group} ° d ONLN d ⁄ O < Z, *
0{ this routine still needs some error checking } ° d ONLN d c n? ( ä 6;{ This routine appends all of the items of a specified DITL ° d ONLN dG m xÄ *
Honto the end of a specified DLOG — We don’t even need to know the format ° d ONLN dê w Ç Y *
of the DLOG } ° d ONLN dû ã ñ ≥ * { this will be done in 3 steps: ° d ONLN dæ ï †] *
A 1. append the items of the specified DITL onto the existing DLOG ° d ONLN d ü ™
9 3. return the adjusted number of the first new user item ° d ONLN dl ≥ æ *
} ° d ONLN do Ω < » P +$
TYPE ° d ONLN dv « ` “ µ +$
DITLItem = RECORD ° d ONLN dà « Ã “D )l{ First, a single item } ° d ONLN d§ — Ñ ‹e ( ¯ ¢-{ Handle or procedure pointer for this item } ° d ONLN d÷ € ® Ê ¯ +$
itmHndl: Handle; ° d ONLN dÍ Â Ñ 3 ( ¢#{ Display rectangle for this item } ° d ONLN d Ô ® ˙ Ó +$
itmRect: Rect; ° d ONLN d% ˘ Ñ8 ( ¢${ Item type for this item — 1 byte } ° d ONLN dN ® +$
itmType: SignedByte; ° d ONLN df
Ñ ˜ (4 ¢{ Length byte of data } ° d ONLN dÇ ®"\ +$
{DITLItem} ° d ONLN dª+ `6 ç (R ~ pDITLItem ° d ONLN d≈+ ®6 È )H
= ^DITLItem; ° d ONLN d’5 `@ ç (\ ~ hDITLItem ° d ONLN dfl5 ®@ Ó )H = ^pDITLItem; ° d ONLN dI `T µ (p ~ItemList = RECORD ° d ONLN dI ÃTS )l{ Then, the list of items } ° d ONLN d!S Ñ^ (z ¢ { Number of items minus 1 } ° d ONLN dB] ®h +$
dlgMaxIndex: Integer; ° d ONLN d[g Ñr fi (é ¢{ Array of items } ° d ONLN drq ®|\ +$
$DITLItems: ARRAY [0..0] OF DITLItem; ° d ONLN dô{ <Ü P (¢ ZEND; ° d ONLN dû{ `Ü ó )$ {ItemList} ° d ONLN d¨Ö `ê ç *
pItemList ° d ONLN d∂Ö ®ê È )H
= ^ItemList; ° d ONLN dΔè `ö ç (∂ ~ hItemList ° d ONLN d–è ®ö Ó )H = ^pItemList; ° d ONLN d·£ `Æ ~ ( ~IntPtr ° d ONLN dÈ£ ®Æ ‰ )H = ^Integer; ° d ONLN d˜∑ <¬ K (fi ZVAR ° d ONLN d˝¡ `à ´ +$
offset : Point; ° d ONLN d
¡ Ãã )l+{ Used to offset rectangles appended items} ° d ONLN d;À `÷ ¶ (Ú ~maxRect: Rect; ° d ONLN dJÀ Ã÷û )l*{ Used to track increases in window size } ° d ONLN dw’ `‡ ø (¸ ~hDITL : hItemList; ° d ONLN d㒠Çq )l!{ Handle to DITL being appended } ° d ONLN dØfl `Í ∫ ( ~pItem : pDITLItem; ° d ONLN d¬fl ÃÍû )l*{ Pointer to current item being appended } ° d ONLN dÔÈ `Ù ∫ ( ~hItems: hItemList; ° d ONLN dÈ ÃÙb )l { Handle to DLOG’s item list } ° d ONLN d#Û `˛ ø ( ~firstItem: Integer; ° d ONLN d7Û Ã˛û )l*{ offset to first item is to be appended } ° d ONLN dd˝ ` ∫ ($ ~newItems: Integer; ° d ONLN dw˝ Ã: )l{ Count of new items } ° d ONLN dê ` ø (. ~dataSize : Integer; ° d ONLN d§ Ãq )l!{ Size of data for current item } ° d ONLN d» ` ° (8 ~
i : Integer; ° d ONLN d◊ à ! )l{ Working index } ° d ONLN dÎ `& ó (B ~ USB: RECORD ° d ONLN d¯ Ã&î )l({ needed because itmData[0] is unsigned} ° d ONLN d$% Ñ0 œ (L ¢CASE Integer OF ° d ONLN d8/ ®: ≤ +$
1: ° d ONLN d@9 ÃDä +$
&(SBArray: ARRAY [0..1] OF SignedByte); ° d ONLN dkC ®N ≤ (j Δ2: ° d ONLN dsM ÃX +$
(Int: Integer); ° d ONLN dÖW `b t (~ ~END; ° d ONLN däW Ñb ¢ )$ {USB} ° d ONLN dík <v Z (í ZBEGIN ° d ONLN dök Ñv ¿ )H {AppendDITL} ° d ONLN dßu Ä (ú 6{
° d ONLN d < ) ¸ ( E Z& 1. Remember the original window Size. ° d ONLN d ' ) < 5h * A 2. Set the offset Point to be the bottom of the original window. ° d ONLN d i 5 < AC * 8 3. Subtract 5 pixels from bottom and right, to be added ° d ONLN d ¢ A < MF * 8 back later after we have possibly expanded window. ° d ONLN d € M < Y * - 4. Get working Handle to original item list. ° d ONLN d Y < eN * = 5. Calculate our first item number to be returned to caller. ° d ONLN dG e < q * - 6. Get locked Handle to DITL to be appended. ° d ONLN du q < } ÿ * ! 7. Calculate count of new items. ,
2hDITL := hItemList(GetResource('DITL',theDITLID)); ° d ONLN d ◊ Ñ ‚ Ì *
HLock(Handle(hDITL)); ° d ONLN d˝ · Ñ Ï8 *
$newItems := hDITL^^.dlgMaxIndex + 1; ° d ONLN d" Î < ˆ A ( Z{
° d ONLN d$ ı < É * For each item, ° d ONLN d4 <
> * 8 1. Offset the rectangle to follow the original window. ° d ONLN dm
<( * 2 2. Make the original window larger if necessary. ° d ONLN d† <% ¸ * + 3. fill in item Handle according to type.
° d ONLN dÃ% <0 A * } ° d ONLN d–9 ÑD +H pItem := @hDITL^^.DITLItems; ° d ONLN dÔC ÑN *
FOR i := 1 TO newItems DO BEGIN ° d ONLN dM ®Xâ +$
-OffsetRect(pItem^.itmRect,offset.h,offset.v); ° d ONLN dCW ®bz *
*UnionRect(pItem^.itmRect,maxRect,maxRect); ° d ONLN dqa ®l È *
USB.Int := 0; ° d ONLN dÄaln )l {zero things out} ° d ONLN dñk ®v\ (í Δ$USB.SBArray[1] := pItem^.itmData[0]; ° d ONLN dæ ®ä¢ *2{ Strip enable bit since it doesn’t matter here. } ° d ONLN dÙâ ®î Ó *
WITH pItem^ DO ° d ONLN dì ÃûI +$
CASE BAND(itmType,$7F) OF ° d ONLN d&ù ®Æ +$
&{ Can’t do anything with user items. } ° d ONLN dRß ≤ *
userItem: ° d ONLN dd±º_ +$
itmHndl := NIL; ° d ONLN dzªΔ™ *
ctrlItem + btnCtrl,ctrlItem + ° d ONLN dü≈–æ *
"chkCtrl,ctrlItem + radCtrl:{build ° d ONLN d»œ⁄< *
Control) ° d ONLN dÿŸ8‰j +$
itmHndl := ° d ONLN d„„ <Ó (
Z*Handle(NewControl(theDialog, { theWindow } ° d ONLN d ˜ m +¥ itmRect, { boundsRect } ° d ONLN dH § *$ StringPtr(@itmData[0])^, { title } ° d ONLN d} *O * true, { visible } ° d ONLN d°3 >| * 0,0,1, { value, min, max } ° d ONLN dŒG Rã * BAND(itmType,$03), { procID } ° d ONLN d˛[ fE * 0)); { refCon } ° d ONLN dep‹ +$
(ctrlItem + resCtrl: BEGIN { Get resource ° d ONLN dEoz_ *
*,"PR 9 - Print Dialogs: Adding Items (÷ˇ5 ) of 13 (Ï Z M.PR.PrintDialogsAdding Items ˇ
ê ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ' 2| +ÿ! theDialog)); { theWindow } ° d ONLN d $ ; < FÜ ( b ZBControlHandle(itmHndl)^^.contrlRect := itmRect; {give it the right ° d ONLN d ~ Y < d s * rectangle} ° d ONLN d ë c n• +ÿ
{An actionProc for a Control ° d ONLN d µ m xñ *
should be installed here} ° d ONLN d ÷ w Ç ( ûEND; ° d ONLN d › w\ Ç∂ )l {Case ctrlItem + ° d ONLN d ¯ Å\ åé *
resCtrl} ° d ONLN d ã ñ∏ ( ≤(statText,editText: { Both need Handle to ° d ONLN d: ï8 †´ +H
8SizeWindow(theDialog,maxRect.right,maxRect.bottom,true); ° d ONLN dWÈ ÑÙ ¸ *
AppendDITL := firstItem; ° d ONLN drÛ `˛ t ( ~END; ° d ONLN d}Û\˛ù )¸
{AppendDITL} ° d ONLN då <Æ (. ZJ{------------------------------------------------------------------------} ° d ONLN dÿ <&h *<PROCEDURE MyJobItems(theDialog: DialogPtr; itemNo: Integer); ° d ONLN d% 0 " (L 6 { ° d ONLN d/ :X *
@ This routine replaces the routine in the pItemProc field in the ° d ONLN d[9 <D +$
(TPPrDlg record. The steps it takes are: ° d ONLN dÖC <NΩ *
M1. Check to see if the item hit was one of ours. This is done by “localizing” ° d ONLN d’M `Xå +$
< the number, assuming that our items are numbered from 0..n ° d ONLN dW <bm (~ Z=2. If it’s one of ours then case it and Handle appropriately ° d ONLN dRa <lY *
93. If it isn’t one of ours then call the old item handler ° d ONLN dåk v " (í 6 } ¡ 4¡˘
thePt ° d ONLN d - 1 < )H: Point; ° d ONLN d 9 ; ® F À ( b ΔthePart ° d ONLN d B ; FF )l
: Integer; ° d ONLN d P E ® P ’ ( l Δ theValue ° d ONLN d Z E P" )H
: Integer; ° d ONLN d h O ® Z ’ ( v Δ debugPart ° d ONLN d r O Z" )H
: Integer; ° d ONLN d c Ñ n ¢ ( ä ¢BEGIN ° d ONLN d ã c\ nù )ÿ
{MyJobItems} ° d ONLN d ú m ® xª ( î Δ7firstItem := prFirstItem; { remember, we saved this in ° d ONLN d ⁄ w Ç} +l
myJobDlgInit } ° d ONLN d Û Å ® åfi ( ® Δ>MyItem := itemNo - firstItem + 1; { “localize” current item No ° d ONLN d2 ã < ñ A ( ≤ Z} ° d ONLN d7 ï ® †fi +l
>IF MyItem > 0 THEN BEGIN { if localized item > 0, it’s one of ° d ONLN d{ ü ™P +l
2GetDItem(theDialog,itemNo,itemType,itemH,itemBox); ° d ONLN dÔ Ω Ã » *
CASE MyItem OF ° d ONLN d « “J +$
MyDFirstBox: BEGIN ° d ONLN d — ‹» +$
${ invert value of FirstBoxValue and ° d ONLN dF € ÊZ *
redraw it } ° d ONLN d[ Â √ *
#FirstBoxValue := 1 - FirstBoxValue; ° d ONLN dÖ ˘ `P ( ~0SetCtlValue(ControlHandle(itemH),FirstBoxValue); ° d ONLN dª +ê
END; ° d ONLN d√Äfl )ê {case MyDFirstBox} ° d ONLN d‹
O (4MyDSecondBox: BEGIN ° d ONLN dˆ"Õ +$
%{ invert value of SecondBoxValue and ° d ONLN d!!,U *
redraw it } ° d ONLN d5+6Õ *
%SecondBoxValue := 1 - SecondBoxValue; ° d ONLN da? `JU (f ~1SetCtlValue(ControlHandle(itemH),SecondBoxValue); ° d ONLN dòI T +ê
END; ° d ONLN d†IÄT£ )ê {case ° d ONLN d±SÄ^À *
MyDSecondBox} ° d ONLN dΔ] h (Ñ OTHERWISE ° d ONLN d÷gr2 +$
Debug; ° d ONLN dfig\rfi )H { OH OH — We got an item ° d ONLN dˇq8|ƒ (òV we didn’t expect } ° d ONLN d { ÃÜ ‡ (¢ ÍEND; ° d ONLN d){ÄÜ£ )¥ {Case} ° d ONLN d4Ö ®ê ∑ (¨ ΔEND ° d ONLN d=ÖÄê⁄ )ÿ { if MyItem > 0 } ° d ONLN dSè ®ö ¡ (∂ ΔELSE ° d ONLN d\è8ö‚ )ê" { chain to standard item handler, ° d ONLN dÜô8§∫ *
whose address is saved ° d ONLN d≤≠∏d (‘2in prPItemProc } ° d ONLN d«∑ ì≤ (fi Í.CallItemHandler(theDialog,itemNo,prPItemProc); ° d ONLN d¯¡ Ñà ò (Ë ¢END; ° d ONLN d¡ÄÃÀ )¸ { MyJobItems } ° d ONLN d’ `‡“ (¸ ~J{------------------------------------------------------------------------} ° d ONLN d`È `ÙP *0FUNCTION MyJobDlgInit(hPrint: THPrint): TPPrDlg; ° d ONLN dëÛ <˛ A ( Z{ ° d ONLN dì˝ <ö *
F This routine appends items to the standard job dialog and sets up the ° d ONLN d⁄ <1 *
1 user fields of the printing dialog record TPRDlg ° d ONLN d < *
) This routine will be called by PrDlgMain ° d ONLN d6 <& ™ *
This is what it does: ° d ONLN dM% <0O *
7 1. First call PrJobInit to fill in the TPPrDlg record. ° d ONLN dÖ/ <:Ü *
B 2. Append our items onto the old DITL. Set them up appropriately. ° d ONLN d»9 <Dö *
F 3. Save the address of the old item handler and replace it with ours. ° d ONLN dC <N *
) 4. Return the Fixed dialog to PrDlgMain. ° d ONLN d9M <X F *
} ° d ONLN d>a Ñl ì +HVAR ° d ONLN dEk ®v ’ +$
firstItem ° d ONLN dOk v§ )H$: Integer; { first new item number } ° d ONLN dv Ñä ¢ (¶ ¢BEGIN ° d ONLN dÇ\äß )ÿ {MyJobDlgInit} ° d ONLN dïâ ®î¿ (∞ Δ8firstItem := AppendDITL(DialogPtr(PrtJobDialog),MyDITL); ¡ X¡
° d ONLN d ' Ñ 2ó +l!7prFirstItem := firstItem; { save this so MyJobItems can ° d ONLN d > 1 <@ +l
find it } ° d ONLN d R E Ñ Pç ( l ¢5{ now we’ll set up our DITL items — The "First Box" } ° d ONLN d ã Y < dã ( Ä ZCGetDItem(DialogPtr(PrtJobDialog),firstItem,itemType,itemH,itemBox); ° d ONLN d “ c Ñ nt +H
0SetCtlValue(ControlHandle(itemH),FirstBoxValue); ° d ONLN d w Ñ Ç∫ *>{ now we’ll set up the second of our DITL items — The "Second ° d ONLN dG Å Ñ å ¨ *
Box" } ° d ONLN dS ã Ñ ñe *
-GetDItem(DialogPtr(PrtJobDialog),firstItem + ° d ONLN dÖ ï Ñ † *
1,itemType,itemH,itemBox); ° d ONLN d£ ü Ñ ™y *
1SetCtlValue(ControlHandle(itemH),SecondBoxValue); ° d ONLN d’ ≥ æÖ ( ⁄ 6I{ Now comes the part where we patch in our item handler. We have to save ° d ONLN d Ω »{ *
G the old item handler address, so we can call it if one of the standard ° d ONLN dg « “
*
1 items is hit, and put our item handler’s address ° d ONLN dô — ‹ Â *
) in pItemProc field of the TPrDlg struct} ° d ONLN dΔ Â Ñ t +l0prPItemProc := LongInt(PrtJobDialog^.pItemProc); ° d ONLN d˙ ˘ Ñ∫ *>{ Now we’ll tell the modal item handler where our routine is } ° d ONLN d< Ñt *
0PrtJobDialog^.pItemProc := ProcPtr(@MyJobItems); ° d ONLN dp Ñ"´ *;{ PrDlgMain expects a pointer to the modified dialog to be ° d ONLN dÆ! Ñ, ‘ *
returned.... } ° d ONLN d¬+ Ñ6 *
MyJobDlgInit := PrtJobDialog; ° d ONLN d‚? `J t (f ~END; ° d ONLN dÌ?\Jß )¸ {myJobDlgInit} ° d ONLN d˛S <^Æ (z ZJ{------------------------------------------------------------------------} ° d ONLN dJg <r ™ *FUNCTION Print: OSErr; ° d ONLN dc{ `Ü o +$VAR ° d ONLN djÖ Ñê ò +$
bool ° d ONLN dqÖ ê" )l
: BOOLEAN; ° d ONLN d~ô `§ ~ (¿ ~BEGIN ° d ONLN däô8§` )ÿ {Print} ° d ONLN dñ£ ÑÆt ( ¢0hPrintRec := THPrint(NewHandle(sizeof(TPrint))); ° d ONLN d ≠ Ñ∏ ¸ *
PrintDefault(hPrintRec); ° d ONLN dÊ∑ Ѭ *
bool := PrValidate(hPrintRec); ° d ONLN d¡ ÑÃ$ *
IF (PrError <> noErr) THEN BEGIN ° d ONLN d-À ®÷ ˝ +$
Print := PrError; ° d ONLN dC’ ®‡ ‰ *
Exit(Print); ° d ONLN dSfl ÑÍ ò ( ¢END; ° d ONLN d]fl\Íu )ÿ {If} ° d ONLN dfÛ Ñ˛µ ( ¢={ call PrJobInit to get pointer to the invisible job dialog } ° d ONLN dß˝ Ñ= *
%PrtJobDialog := PrJobInit(hPrintRec); ° d ONLN d– Ñ$ *
IF (PrError <> noErr) THEN BEGIN ° d ONLN dı ® ˝ +$
Print := PrError; ° d ONLN d ®& ‰ *
Exit(Print); ° d ONLN d% Ñ0 ò (L ¢END; ° d ONLN d%%\0u )ÿ {If} ° d ONLN d+9 D Ã (` 6$ {Here’s the line that does it all!} ° d ONLN dSC ÑNí +l
6IF NOT (PrDlgMain(hPrintRec,@MyJobDlgInit)) THEN BEGIN ° d ONLN déM ®X ¯ +$
Print := cancel; ° d ONLN d£W ®b ‰ *
Exit(Print); ° d ONLN d≥a Ñl ò (à ¢END; ° d ONLN dΩa\lu )ÿ {If} ° d ONLN dΔu ÑÄV (ú ¢*IF PrError <> noErr THEN Print := PrError; ° d ONLN dÙâ Ñî Ú *{ that’s all for now } ¡ 4¡˘
{ Print } ° d ONLN d ; ` F“ ( b ~J{------------------------------------------------------------------------} ° d ONLN d c O ` Z ~ *BEGIN ° d ONLN d p O\ Zé )¸
{PROGRAM} ° d ONLN d } c Ñ n Ú ( ä ¢UnloadSeg(@_DataInit); ° d ONLN d î c n‹ )ê( {remove data initialization code before ° d ONLN d √ m xn *
any allocations} ° d ONLN d ÿ w Ñ Ç „ ( û ¢InitGraf(@thePort); ° d ONLN d Ó Å Ñ å ∂ *
InitCursor; ° d ONLN d` — Ñ ‹G *'{ call the routine that does printing } ° d ONLN dä € Ñ Ê „ *
FirstBoxValue := 0; ° d ONLN dü € Ê“ )ê& { value of our first additional box } ° d ONLN d» Â Ñ Ì ( ¢SecondBoxValue := 0; ° d ONLN dfi  √ )ê# { value of our second addtl. box } ° d ONLN d Ô Ñ ˙= ( ¢%PrOpen; { Open the Print Manager } ° d ONLN d, ˘ Ñ ˜ *
IF PrError = noErr THEN ° d ONLN dG ®‘ +$
<err := Print { This actually brings up the modified Job ° d ONLN dà
1 +H
dialog } ° d ONLN dò Ñ" ∂ (> ¢
ELSE BEGIN ° d ONLN d¶! ®,R +$
"{tell the user that PrOpen failed} ° d ONLN dÀ+ Ñ6 ò (R ¢END; ° d ONLN d“? ÑJy *1PrClose; { Close the Print Manager and leave } ° d ONLN dI `T t (p ~END.
° d ONLN d
k <z. (ñ Z The Lightspeed C Example Program
° d ONLN d+Ü <í† *J/* NOTE: Apple reserves the top half of the screen (where the current DITL ° d ONLN dví <ûT * <items are located). Applications may use the bottom half of ° d ONLN d≤íTû˛ (∫r#the screen to add items, but should ° d ONLN d÷û <™ Ê (Δ Z%not change any items in the top half ° d ONLN d¸û ™9 )¥of the screen. ° d ONLN d û9™˛ )I&An application should expand the print ° d ONLN d2™ <∂ (“ Z0dialogs only as much as is absolutely necessary.
° d ONLN dc∂ <¡ F * */ ° d ONLN df <’ï *E/* Note: A global search and replace of 'Job' with 'Stl' will produce ° d ONLN dÆ‘ `fl# +$
'code that modifies the style dialogs */ ° d ONLN d÷fi <È ™ ( Z#include <DialogMgr.h> ° d ONLN dÌË <Û • *
#include <MacTypes.h> ° d ONLN dÚ <˝ ™ *
#include <Quickdraw.h> ° d ONLN d¸ < ¥ *
#include <ResourceMgr.h> ° d ONLN d3 < ™ *
#include <WindowMgr.h> ° d ONLN dJ < õ *
#include <pascal.h> ° d ONLN d^ <% • *
#include <printmgr.h> ° d ONLN dt$ </ Ç *
#define nil 0L ° d ONLN dÉB <M » * static TPPrDlg PrtJobDialog; ° d ONLN d°BMõ )ÿ/* pointer to job dialog */ ° d ONLN dΩV <a F (} Z/* ° d ONLN d¿V `a# )$'This points to the following structure: ° d ONLN dÎj `u í *
struct { ° d ONLN d˘t Ñ +$
DialogRecord ° d ONLN dt )lDlg; ° d ONLN d
t )$ ° d ONLN dt8ó )$(The Dialog window) ° d ONLN d&~ Ñâ ± (• ¢ ProcPtr ° d ONLN d1~ â" )l
pFltrProc; ° d ONLN d<~8âí )H(The Filter Proc.) ¡ X¡
pItemProc; ° d ONLN d (™ )H (The Item evaluating proc. -- ° d ONLN d ; ' 2J ( Nwe'll change this) ° d ONLN d P 1 ` < ç ( X ~ THPrint ° d ONLN d [ 1 Ã < ˛ )l
hPrintUsr; ° d ONLN d f 1 <ñ )H(The user's print record.) ° d ONLN d É ; ` F ç ( b ~ Boolean ° d ONLN d é ; à F Í )lfDoIt; ° d ONLN d ò E ` P ç ( l ~ Boolean ° d ONLN d £ E à P Í )lfDone; ° d ONLN d ≠ O ` Z j ( v ~ ° d ONLN d ∞ O Ñ ZV )$*(Four longs -- reserved by Apple Computer) ° d ONLN d › Y ` d ~ ( Ä ~ long ° d ONLN d Ê Y à d Ô )llUser1; ° d ONLN d Û c ` n ~ ( ä ~ long ° d ONLN d ¸ c à n Ô )llUser2; ° d ONLN d m ` x ~ ( î ~ long ° d ONLN d m à x Ô )llUser3; ° d ONLN d w ` Ç ~ ( û ~ long ° d ONLN d% w Ã Ç Ô )llUser4; ° d ONLN d/ Å å ê ( ® 6 } TPrDlg; *TPPrDlg; ° d ONLN dJ ã ñ " *
on to job dialog */ ° d ONLN d“ r (* 6THPrint hPrintRec; ° d ONLN dÁ ÃX )¥ /* handle to print record */ ° d ONLN d
ê (4 6short FirstBoxValue = 0; ° d ONLN d
Ãè )¥'/* value of our first additional box */ ° d ONLN dF " ï (> 6short SecondBoxValue = 0; ° d ONLN da Ã"Ä )¥$/* value of our second addtl. box */ ° d ONLN dÜ! , m (H 6long prFirstItem; ° d ONLN dõ! ,Ü )ÿ /* save our first item here */ ° d ONLN d∫+ 6 m (R 6long prPItemProc; ° d ONLN dŒ+ Ã6® )¥,/* we need to store the old itemProc here */ ° d ONLN d˚? Jè (f 6K/*-----------------------------------------------------------------------*/ ° d ONLN dHI <T n +$
WindowPtr ° d ONLN dSI ÑT ± )H MyWindow; ° d ONLN d^S <^ Z (z ZOSErr ° d ONLN deS `^ t )$err; ° d ONLN dk] <h _ (Ñ ZStr255 ° d ONLN ds] Ñh ¢ )HmyStr; ° d ONLN dzg r 6 (é 6main() ° d ONLN dÅq | *
{ ° d ONLN dÖ{ <Ü U +$
Rect ° d ONLN då{ ÑÜ ¨ )HmyWRect; ° d ONLN dòè <ö õ (∂ ZInitGraf(&thePort); ° d ONLN d≠ô <§ x *
InitFonts(); ° d ONLN dª£ <Æ Ç *
InitWindows(); ° d ONLN dÀ≠ <∏ x *
InitMenus(); ° d ONLN dŸ∑ <¬ ë *
InitDialogs(nil); ° d ONLN dÏ¡ <à } *
InitCursor(); ° d ONLN d˙À ÷ ' (Ú 6 ° d ONLN d˛À <÷ · )$!SetRect(&myWRect,50,260,350,340); ° d ONLN d#fl <Í *)/* call the routine that does printing */ ° d ONLN dNÈ <Ù i *
PrOpen(); ° d ONLN dYÛ <˛ Ç *
err = Print(); ° d ONLN dk < n *
PrClose(); ° d ONLN dv T (8 6 } /* main */ ° d ONLN dÉ% 0î *L/*------------------------------------------------------------------------*/ ° d ONLN d–9 D Y *
OSErr Print() ° d ONLN dfiM X *{ ° d ONLN d·W <bw +$
?/* call PrJobInit to get pointer to the invisible job dialog */ ° d ONLN d"a <l1 *
1hPrintRec = (THPrint)(NewHandle(sizeof(TPrint))); ° d ONLN dUk <v ¥ *
° d ONLN d ' ` 2 ( N ~$PrtJobDialog = PrJobInit(hPrintRec); ° d ONLN d & 1 ` < ” *
if (PrError() != noErr) ° d ONLN d @ ; Ñ F Ÿ +$
return PrError(); ° d ONLN d W Y ` d- ( Ä ~)if (!PrDlgMain(hPrintRec, &MyJobDlgInit)) ° d ONLN d Å Y8 d‚ )ÿ"/* this line does all the stuff */ ° d ONLN d ¶ c Ñ n ( ä ¢return Cancel; ° d ONLN d ∂ w ` Ç ” ( û ~if (PrError() != noErr) ° d ONLN d – Å Ñ å Ÿ +$
} /* Print */ ° d ONLN d Ω < »∏ *L/*------------------------------------------------------------------------*/ ° d ONLN d] — < ‹ *$pascal TPPrDlg MyJobDlgInit (hPrint) ° d ONLN dÇ € < Ê á *
THPrint hPrint; ° d ONLN dí Â < § *
H/* this routine appends items to the standard job dialog and sets up the ° d ONLN d‹ Ô ` ˙P +$
0user fields of the printing dialog record TPRDlg ° d ONLN d ˘ `7 *
+This routine will be called by PrDlgMain */ ° d ONLN d; < A (* Z{ ° d ONLN d>
` y +$
short ° d ONLN dE
® ⁄ )H
firstItem; ° d ONLN dQ
õ )l/* first new item number */ ° d ONLN dp! `, y (H ~short ° d ONLN dw! ®, ’ )H itemType; ° d ONLN dÇ!,◊ )l'/* needed for GetDItem/SetDItem call */ ° d ONLN d´+ `6 ~ (R ~Handle ° d ONLN d≤+ Ñ6 ¢ )$itemH; ° d ONLN d∫5 `@ t (\ ~Rect ° d ONLN d¿5 ®@ – )HitemBox; ° d ONLN dÃI `T¥ (p ~DfirstItem = AppendDITL (PrtJobDialog, MyDITL); /*call routine to do ° d ONLN dS8^[ +ÿ
this */ ° d ONLN d$g `r™ (é ~BprFirstItem = firstItem; /* save this so MyJobItems can find it */ ° d ONLN di{ <ÜT (¢ Z8/* now we'll set up our DITL items -- The "First Box" */ ° d ONLN d£Ö `êá +$
;GetDItem(PrtJobDialog,firstItem,&itemType,&itemH,&itemBox); ° d ONLN d‡è `ö *
!SetCtlValue(itemH,FirstBoxValue); ° d ONLN d£ <Ƨ ( ZH/* now we'll set up the second of our DITL items -- The "Second Box" */ ° d ONLN dN≠ `∏ë +$
=GetDItem(PrtJobDialog,firstItem+1,&itemType,&itemH,&itemBox); ° d ONLN dç∑ `¬
*
"SetCtlValue(itemH,SecondBoxValue); ° d ONLN d≤À <÷Æ (Ú ZJ/* Now comes the part where we patch in our item handler. We have to save ° d ONLN d˛’ `‡ +$
Pthe old item handler address, so we can call it if one of the standard items is ° d ONLN dOfl `ÍÎ *
Ohit, and put our item handler's address in pItemProc field of the TPrDlg struct ° d ONLN düÈ <Ù F ( Z*/ ° d ONLN d£˝ `< +$,prPItemProc = (long)PrtJobDialog->pItemProc; ° d ONLN d“ < | (8 Z@/* Now we'll tell the modal item handler where our routine is */ ° d ONLN d `&K +$
/PrtJobDialog->pItemProc = (ProcPtr)&MyJobItems; ° d ONLN dF/ <:≥ (V ZK/* PrDlgMain expects a pointer to the modified dialog to be returned.... */ ° d ONLN dì9 `D ƒ +$
return PrtJobDialog; ° d ONLN d™M <X ñ (t Z} /*myJobDlgInit*/ ° d ONLN dΩk <v≥ * K/*-----------------------------------------------------------------------*/ ° d ONLN d <ä' *//* here's the analogue to the SF dialog hook */ ¡ X¡
*0"PR 9 - Print Dialogs: Adding Items (÷˙11 )
of 13 (Ï Z M.PR.PrintDialogsAdding Items ˇ î ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( ‡ *(pascal void MyJobItems(theDialog,itemNo) ° d ONLN d ) ' 2 ; *
TPPrDlg ° d ONLN d 1 ' ` 2 í )H
theDialog; ° d ONLN d < 1 < 6 ( X 6short ° d ONLN d C 1 < < _ )$itemNo; ° d ONLN d K E P r ( l 6{ /* MyJobItems */ ° d ONLN d _ O < Z Z +$
short ° d ONLN d f O ` Z É )$myItem; ° d ONLN d o Y < d Z ( Ä Zshort ° d ONLN d v Y ` d í )$
firstItem; ° d ONLN d Ñ m < x U ( î Zshort ° d ONLN d ã m Ñ x ± )H itemType; ° d ONLN d ñ m x≥ )l'/* needed for GetDItem/SetDItem call */ ° d ONLN d ø w < Ç Z ( û ZHandle ° d ONLN d Δ w ` Ç ~ )$itemH; ° d ONLN d Œ Å < å P ( ® ZRect ° d ONLN d ‘ Å Ñ å ¨ )HitemBox; ° d ONLN d ‡ ï < †ö ( º ZFfirstItem = prFirstItem; /* remember, we saved this in myJobDlgInit */ ° d ONLN d( ü < ™ » *
° d ONLN d A < M ¶ ( i ZFurther Reference: l X l ° d ONLN d N N Z R +
• ° d ONLN d N ` Z « )The Printing Manager ° d ONLN d * Z N f R ( Ç l• ° d ONLN d , Z ` f ¿ )The Dialog Manager ¡ X¡
(÷ Z"PR 9 - Print Dialogs: Adding Items (÷˙13 )
of 13 (Ï Z M.PR.PrintDialogsAdding Items ˇû ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åy ( õ Z#PR 10 - A Printing Loop That Cares…
° d ONLN d $ Ä < è s *Printing
° d ONLN d . õ < ß t * Revised by: ° d ONLN d : õ Ñ ß )HPete “Luke” Alexander ° d ONLN d P õæ ߲ ( √‹ October 1990 ° d ONLN d ] ß < ≥ q ( œ Z Written by: ° d ONLN d i ß Ñ ≥ – )HGinger Jernigan ° d ONLN d y ß± ≥˛ ( œœSeptember 1987 ° d ONLN d à ø < À W ( Á ZThis ° d ONLN d ç ø W À˛ )OTechnical Note discusses opening and closing the Printing Manager with calls to ,
Courier ° d ONLN d › À < ◊ m ( Ù Z_PrOpen ° d ONLN d ‰ Ã m ÿ Ñ )1 and ° d ONLN d È À Ñ ◊ º )_PrClose ° d ONLN d Ò Ã º ÿë )8/ as well as how to handle errors at print time. ° d ONLN d! ÿ < ‰ ì ( ZChanges since ° d ONLN d/ ÿ ì ‰ Â )W
October 1989: ° d ONLN d< ÿ  ‰˛ )R8 Added the section on error checking, incorporating the ° d ONLN du ‰ < ( Z*error code descriptions formerly found in ° d ONLN dü ‰ ˛ )‰&Technical Note #72, Optimizing For The ° d ONLN dΔ < ¸— ( ZJLaserWriter—Techniques and an updated version of the information formerly ° d ONLN d — ¸˛ (Ôfound in ° d ONLN d ¸ <u ($ Z=Technical Note #118, How To Check and Handle Printing Errors. 3 X3
° d ONLN dW! <0 è *( Introduction
° d ONLN dd= <I5 */At one time, Apple recommended that developers ° d ONLN dì=5IK )˘call ° d ONLN dò<KH| )_PrOpen ° d ONLN dü=|I˛ )1 at the beginning of their ° d ONLN d∫J <V à (r Zapplication and ° d ONLN d I àU ¿ )L_PrClose ° d ONLN d“J ¿Vñ )8. at the end, before returning to the Finder. ° d ONLN d JñV˛ )÷This recommendation ° d ONLN dV <bŸ (~ ZZwas in the ancient past when an application only had to deal with a single printer driver. ° d ONLN don <z∑ *QAs more printer drivers became available, it became important for an application ° d ONLN d¿n∑z˛ (ñ’to consider the ° d ONLN d–z <Üt (¢ Z?presence of other applications and how opening and closing the ° d ONLN dztܲ (¢í printer driver affected them. ° d ONLN d.Ü <í € (Æ Z The user could open the Chooser ° d ONLN dNÜ €í˛ )ü=at any time and change the current printer driver without the ° d ONLN dåí <ûÍ (∫ ZVcurrent application’s knowledge. If an application followed the old philosophy and a ° d ONLN d‚íÍû˛ (∫user ° d ONLN dÁû <™ (Δ Z)changed the current printer driver while ° d ONLN dû ™˛ )œ/running the application, the next time the user ° d ONLN d@™ <∂ö (“ ZIattempted to print, the wrong driver would be open, the Printing Manager ° d ONLN dâ™ö∂˛ (“∏would not be able to ° d ONLN dû∂ <¬_ (fi Z>find the necessary resources, and the user would get an error.
° d ONLN d›⁄ <È *'The Current Recommendation
° d ONLN d¯ı <a *:DTS currently recommends that applications open and close ° d ONLN d2ıaπ ( the printer driver ° d ONLN dEıπ“ )Xeach ° d ONLN dIı“˛ ) time the ° d ONLN dS <
Ò () Z&application uses the Printing Manager. ° d ONLN dz <% É *
MPW Pascal
° d ONLN dÖ1 <<÷ *R*------ PrintStuff --------------------------------------------------------------- ° d ONLN d◊1÷<€ (XÙ- ° d ONLN dÿ; <F F (b Z*} ° d ONLN d€E <P K *
{** ° d ONLN dflO <Z K *
** ° d ONLN d„O `Zæ )$FPrintStuff will call all of the necessary Print Manager calls to print ° d ONLN d*Y <d K (Ä Z ** ° d ONLN d.Y `dæ )$Fa document. It checks PrError() after each Print Manager call. If an ° d ONLN duc <n K (ä Z ** ° d ONLN dyc `n™ )$Berror is found, all of the Print Manager open calls (i.e., PrOpen, ° d ONLN dºm <x K (î Z ** ° d ONLN d¿m `xØ )$CPrOpenDoc...) will have a corresponding close call before the error ° d ONLN dw <Ç K (û Z ** ° d ONLN dw `Çæ )$Fis posted to the user. You want to use this approach to make sure the ° d ONLN dOÅ <å K (® Z ** ° d ONLN dSÅ `åØ )$CPrint Manager closes properly and all temporary memory is released. ° d ONLN dóã <ñ P (≤ Z **} ¡ X¡
*$#PR 10 - A Printing Loop That Cares… (÷ˇ1 ) of 11 (Ï ZM.PR.PrintLoop ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø Œ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ' 2 Å *!PROCEDURE PrintStuff; ° d ONLN d ; F ' *VAR ° d ONLN d E P E *
copies, ° d ONLN d $ O Z T *
firstPage, ° d ONLN d 1 Y d O *
lastPage, ° d ONLN d = c n ; *
loop, ° d ONLN d E m x m *
numberOfCopies, ° d ONLN d W w Ç Y *
pageNumber, ° d ONLN d e Å å w *
printmgrsResFile, ° d ONLN d y ã ñ Ã *
$ realNumberOfPagesInDoc : Integer; ° d ONLN d û ï † Ã *
& theStatus : TPrStatus; ° d ONLN dZ — ‹ 1 *BEGIN ° d ONLN d` € Ê w *
GetPort(oldPort); ° d ONLN dt Ô ˙ 1 * {** ° d ONLN dz ˘ ∑ *
S UnLoadTheWorld will swap out ALL unneeded code segments and data that are NOT ° d ONLN dŒ ^ *
required ° d ONLN d›
Ö *
I during print time. Your print code must be a separate code segment. ° d ONLN d' " 1 *
**} ° d ONLN d-! , m *
UnLoadTheWorld; ° d ONLN d?5 @ *4 thePrRecHdl := THPrint(NewHandle(SIZEOF(TPrint))); ° d ONLN dtI T! *5 IF (MemError = noErr) AND (thePrRecHdl <> NIL) THEN ° d ONLN d™S ^ E *
BEGIN ° d ONLN d¥] h Y *
PrOpen; ° d ONLN d¬g r Ω *
! IF (PrError = noErr) THEN ° d ONLN d‰q | c *
BEGIN ° d ONLN dÙ{ Ü c *
{** ° d ONLN dÖ êä *
J Save the current resource file (i.e. the printer driver's) ° d ONLN dOè öä *
J so the driver will not lose its resources upon return from ° d ONLN döô § Æ *
= thePrRecHdl^^.prJob.iLstPage := 9999; ° d ONLN d;+ <6 √ * {** ° d ONLN dW5 <@Ω *
M Determine the "real" number of pages contained in ° d ONLN d•? <JΩ *
M the document. Without this test, you would print ° d ONLN dÛI <T ˇ *
' 9999 pages. ° d ONLN dS <^ » *
**} ° d ONLN d8g <rã *C IF (realNumberOfPagesinDoc < lastPage) THEN ° d ONLN d|q <|m *
= lastPage := realNumberOfPagesinDoc; ° d ONLN d∫Ö <ê‡ *T PrintingStatusDialog := GetNewDialog(257, NIL, POINTER(-1)); ° d ONLN d(ô <§ √ * {** ° d ONLN dD£ <Æ€ *
S Print the number of copies of document requested by the ° d ONLN dõ≠ ®∏ ⁄ +l
user ° d ONLN d¶∑ <¬J (fi Z6 from the Print Job Dialog. ° d ONLN d›¡ <à » *
**} ° d ONLN d˙’ <‡h *< For copies := 1 To numberOfCopies Do ° d ONLN d7fl <Í ◊ *
BEGIN ° d ONLN dWÛ <˛ ◊ * {** ° d ONLN dw˝ <— *
Q Install a pointer to your pIdle proc in my print ° d ONLN dà à +ê
record. ° d ONLN dÿ < ‹ (8 Z **} ° d ONLN d˘ <&r *
> thePrRecHdl^^.prJob.pIdleProc := ° d ONLN d>% Ã0N +ê
@checkMyPrintDialogButton; ° d ONLN dY9 <D ◊ (` Z {** ° d ONLN dyC <N÷ *
R Restore the resource file to the printer driver's. ° d ONLN dÃM <X ‹ *
**} ° d ONLN dÌW <bY *
9 UseResFile(printmgrsResFile); ° d ONLN d 'k <vÆ *J thePrPort := PrOpenDoc(thePrRecHdl, NIL, NIL); ° d ONLN d r <äE *5 IF (PrError = noErr) THEN ° d ONLN d ®â <î Î *
# BEGIN ¡ X¡
*&#PR 10 - A Printing Loop That Cares… (÷ˇ3 ) of 11 (Ï ZM.PR.PrintLoop ˇ~ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( « *# {** ° d ONLN d $ ' 2ô *
M Print the range of pages of the document ° d ONLN d w 1 Ã < ˘ +¥
requested ° d ONLN d Å ; Fä ( b 6J by the user from the Print Job Dialog. ° d ONLN d à E P à *
$ **} ° d ONLN d Ò O Z0 *
8 pageNumber := firstPage; ° d ONLN d* Y d£ *
O WHILE ((pageNumber <= lastPage) AND (PrError = ° d ONLN d} c ® n È +ê
noErr)) DO ° d ONLN dã m x € ( î 6' BEGIN ° d ONLN d≥ Å åS *? PrOpenPage(thePrPort, NIL); ° d ONLN dÛ ï †S *? IF (PrError = noErr) THEN ° d ONLN d3 ü ™ ˘ *
P rPage (IM II-150) is the printable ° d ONLN d‡ Ω »û *
N area for the currently selected ° d ONLN d5 « “' +ÿ
printer. ° d ONLN dA — ‹≤ ( ¯ 6R By passing the current enables your ° d ONLN dô € ÊΩ +ÿ
) app to use the same routine to draw to ° d ONLN d» Â Ã º ( Í0 the screen and the printer's GrafPort. ° d ONLN d˘ Ô ˙ ˛ ( 6. **} ° d ONLN d( ® *P DrawStuff (thePrRecHdl^^.prInfo.rPage, ° d ONLN dz
Ö *
I GrafPtr (thePrPort), ° d ONLN d≈ "] *
A pageNumber); ° d ONLN d! , Ù *
, END; ° d ONLN d4+ 6I *
= PrClosePage(thePrPort); ° d ONLN dr5 @g *
C pageNumber := pageNumber + 1; ° d ONLN d∂? Jq *
E END; {** End pagenumber loop **} ° d ONLN d¸I T ¬ *
' DisposHandle(Handle (thePrRecHdl)); ° d ONLN d « < “ ˇ *' IF (PrintingStatusDialog <> NIL) THEN ° d ONLN d- — < ‹ ˇ *
' DisposDialog(PrintingStatusDialog); ° d ONLN dU Â < õ * SetPort(oldPort); ° d ONLN di Ô < ˙ æ *
END; {** PrintStuff **}
° d ONLN dÑ < h *MPW C
° d ONLN dä <(€ *S/*------ PrintStuff --------------------------------------------------------------- ° d ONLN d› €(‡ (D˘- ° d ONLN dfi' <2 F (N Z*/ ° d ONLN d·1 << K *
** ° d ONLN dÂ; <FΩ *
M ** PrintStuff will call all of the necessary Print Manager calls to print ° d ONLN d3E <P— *
Q ** a document. It checks PrError() after each Print Manager call. If an error ° d ONLN dÖO <Z— *
Q ** is found, all of the Print Manager open calls (i.e., PrOpen, PrOpenDoc...) ° d ONLN d◊Y <d€ *
S ** will have a corresponding close call before the error is posted to the user. ° d ONLN d+c <n€ *
S ** You want to use this approach to make sure the Print Manager closes properly ° d ONLN dm <x *
, ** and all temporary memory is released. ° d ONLN d¨w <Ç P *
**/ ° d ONLN d±ã <ñ ñ *void PrintStuff () ° d ONLN dƒï <† A *
Q were requested to be printed by the user from iFstPage ° d ONLN d˚Û ˛î *
L and iLastPage from the TPrJob record (IM II-151). ° d ONLN dH˝ ü *
**/ ° d ONLN dd ] *A firstPage = (**thePrRecHdl).prJob.iFstPage; ° d ONLN d¶ &X *
@ lastPage = (**thePrRecHdl).prJob.iLstPage; ° d ONLN dÁ/ : ö * /** ° d ONLN d9 DN *
> Print "all" pages in the print loop ° d ONLN dAC N ü *
**/ ° d ONLN d]W b5 *9 (**thePrRecHdl).prJob.iFstPage = 1; ° d ONLN dóa lD *
< (**thePrRecHdl).prJob.iLstPage = 9999; ¡ 4¡˘
*N6 ) of 11 (÷Z#PR 10 - A Printing Loop That Cares… +YM.PR.PrintLoop ˇ* ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1990 / X / ,
Courier
° d ONLN d ' < 2 æ ( N Z /** ° d ONLN d 1 < <— *
Q Determine the "real" number of pages contained in the ° d ONLN d o ; ® FŸ +l
= document. Without this test, you would print 9999 pages. ° d ONLN d ≠ E < P √ ( l Z **/ ° d ONLN d … Y < dh *< if (realNumberOfPagesinDoc < lastPage) ° d ONLN d c < n^ *
: lastPage = realNumberOfPagesinDoc; ° d ONLN dB w < LJ *T PrintingStatusDialog = GetNewDialog(257, nil, (WindowPtr) -1); ° d ONLN dó ã < ñ æ * /** ° d ONLN d≤ ï < †ï *
E Print the number of copies of the document ° d ONLN d¯ ü < ™≥ *
*:8 ) of 11 (÷Z#PR 10 - A Printing Loop That Cares… +YM.PR.PrintLoop ˇD ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d < )ä ( E ZFThe following section outlines some general error-handling guidelines. ° d ONLN d G 6 N B R +• ° d ONLN d I 6 [ B ‹ )
You should avoid calling ,
Courier ° d ONLN d b 5 ‹ A
)ÅPrError ° d ONLN d i 6
B5 )1 within ° d ONLN d q 65 B⁄ )(!your pIdle procedure; errors that ° d ONLN d ì B [ N ( j y(occur while it is executing are usually ° d ONLN d ª B N⁄ )¥*temporary and serve only as internal flags ° d ONLN d Ê N [ Z ( v y%for communication within the printer ° d ONLN d N Z⁄ )ø$driver—they are not intended for the ° d ONLN d0 [ [ g ( É y*application. If you absolutely must call ° d ONLN dZ Z fP )ƒPrError ° d ONLN da [P gv )1 within ° d ONLN di [v g⁄ )&your idle procedure, ° d ONLN d~ g [ sø ( è yLand an error occurs, never abort printing within the idle procedure itself. ° d ONLN d gø s⁄ ( è› Wait ° d ONLN d– s [ µ ( õ yuntil the last called ° d ONLN dÊ s µ ⁄ )Z@printing procedure returns, then check to see if the error still ° d ONLN d' [ ã Ë ( ß y remains. Attempting to abort ° d ONLN dE Ë ã⁄ )ç3printing within an idle procedure is a guarantee of ° d ONLN dy ã [ ó ö ( ≥ ycertain death. ° d ONLN dà £ N Ø R ( À l• ° d ONLN dä £ [ Ø ¥ )
Upon detecting an ° d ONLN dú £ ¥ Ø⁄ )Y>error after the completion of a printing routine, stop drawing ° d ONLN d€ Ø [ ª ± ( ◊ yat that point, and ° d ONLN dÓ Ø ± ª⁄ )V:proceed to the next procedure to close any previously made ° d ONLN d) º [ » ë ( ‰ y open calls. ° d ONLN d5 º ë » )63 For example, if you detect an error after calling ° d ONLN dh ª «æ )Ó PrOpenDoc ° d ONLN dq ºæ »⁄ )?, skip ° d ONLN dx … [ ’ g ( Ò yto ° d ONLN d{ … g ’ ë ) the next ° d ONLN dÑ » ë ‘ ◊ )*
PrCloseDoc ° d ONLN dé … ◊ ’ê )F). Or, if you get an error after calling ° d ONLN d∑ »ê ‘÷ )π
PrOpenPage ° d ONLN d¡ …÷ ’⁄ )F, ° d ONLN d√ ÷ [ ‚ ¶ ( ˛ yskip to the next ° d ONLN d‘ ’ ¶ · Û )K PrClosePage ° d ONLN dfl ÷ Û ‚
)M and ° d ONLN d‰ ’
·P )
PrCloseDoc ° d ONLN dÓ ÷P ‚Æ )F. Remember that if ° d ONLN d ÷Æ ‚⁄ )^you have ° d ONLN d „ [ Ô z ( ycalled ° d ONLN d ‚ z Ó § ) PrOpen ° d ONLN d „ § Ôc )*', then you must call the corresponding ° d ONLN d? ‚c Óî )øPrClose ° d ONLN dF „î Ô• )1 to ° d ONLN dJ „• Ô⁄ ) ensure that ° d ONLN dV Ô [ ˚T ( y2printing closes properly and all temporary memory ° d ONLN dà ÔT ˚⁄ )˘ allocations are released and ° d ONLN d• ˚ [ º (# yreturned to the heap. ° d ONLN dª N R (; l• ° d ONLN dΩ [ ^ )
6Do not display any alert or dialog boxes to report an ° d ONLN dÛ^ ⁄ (;|error until the end of the ° d ONLN d [+ Õ (G yprinting loop. Once at ° d ONLN d& Õ+⁄ )r8the end, check for the error again; if there is no error ° d ONLN d_+ [7Ñ (S y@assume that printing completed normally. If the error is still ° d ONLN dü+Ñ7⁄ (S¢present, then you ° d ONLN d±7 [C Æ (_ ycan alert the user. ° d ONLN dΔO [[ª *MThis technique is important for two reasons. First, if you display a dialog ° d ONLN dOª[⁄ (wŸbox in ° d ONLN d[ [gœ (É yJthe middle of the printing loop, it could cause errors that can terminate ° d ONLN dd[œg⁄ (ÉÌan ° d ONLN dgg [sQ (è y3otherwise normal job. For example, if the printer ° d ONLN dögQs⁄ )ˆ is an AppleTalk printer, the ° d ONLN d∑s [¨ (õ yBconnection can be terminated abnormally since the driver would be ° d ONLN d˘s¨⁄ (õ unable to ° d ONLN d [ã Ö (ß yrespond ° d ONLN d Öã⁄ )*Dto AppleTalk requests received from the printer while the dialog box ° d ONLN dPã [ó (≥ y%was waiting for input from the user. ° d ONLN duãó⁄ )º& If the printer does not hear from the ° d ONLN dúó [£- (ø y-Macintosh with a short period of time (e.g., ° d ONLN d…ó-£⁄ )“#30 seconds), it times out, assuming ° d ONLN dÌ£ [Øa (À y5that the Macintosh is no longer there, which results ° d ONLN d"£aØ⁄ (Àin a prematurely broken ° d ONLN d:Ø [ªØ (◊ yGconnection causing another error to which the application must respond. ° d ONLN dÉ« [” — *In addition, the driver ° d ONLN dõ« —”⁄ )v0may have already displayed its own dialog box in ° d ONLN dÔ [flà (˚ yJresponse to an error. In this instance, the driver posts an error to let ° d ONLN d ”Ãfl⁄ (˚Íthe ° d ONLN d fl [Î… ( yJapplication know that something went wrong and it should abort printing. ° d ONLN d dfl…Î⁄ (ÁFor ° d ONLN d hÎ [˜ ∑ ( yexample, when the ° d ONLN d zÎ ∑˜⁄ )\<LaserWriter driver detects that the Laser Prep version which ° d ONLN d ∑˜ [Δ ( yMhas been downloaded to the LaserWriter is different than that with which the ° d ONLN d
˜Δ⁄ ( ‰user ° d ONLN d
[* (+ y0is trying to print, it displays the appropriate ° d ONLN d
9*⁄ )œ$dialog box informing the user of the ° d ONLN d
^ [ ¡ (7 ysituation and giving ° d ONLN d
s ¡⁄ )f:him the option of reinitializing the printer. If the user ° d ONLN d
Æ ['á (C yAchooses to cancel printing, the driver posts an error to let the ° d ONLN d
Ôá'⁄ (C•application know ° d ONLN d ' [3 x (O ythat it ° d ONLN d ' x3⁄ ) Kneeds to abort, but since the driver has already taken care of the error by ° d ONLN d T3 [?å ([ y?displaying a dialog box, the error is reset to zero before the ° d ONLN d ì3å?⁄ ([™printing loop is ° d ONLN d §? [KÃ (g yJcomplete. The application should check for the error again at the end of ° d ONLN d Ó?ÃK⁄ (gÍthe ° d ONLN d ÚK [WC (s y7printing loop, and if it still indicates an error, the ° d ONLN d )KCW⁄ )Ë application can then display the ° d ONLN d JW [c … ( yappropriate dialog box. ¡ X¡
(÷ Z#PR 10 - A Printing Loop That Cares… (÷ˇ9 ) of 11 (Ï ZM.PR.PrintLoop ˇÃ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d * * 6 . +%• ° d ONLN d * 7 6 m )
If using ,
Courier ° d ONLN d ) m 5 ¨ )6 PrGeneral ° d ONLN d * ¨ 6∂ )?., be prepared to receive the following errors: ° d ONLN d D 6 7 B v ( _ U NoSuchRsl ° d ONLN d M 7 v C Å )?, ° d ONLN d O 6 Å B ¿ ) OpNotImpl ° d ONLN d X 7 ¿ C „ )?, and ° d ONLN d ^ 6 „ B0 )# resNotFound ° d ONLN d i 70 CÉ )M. In all three ° d ONLN d y 7É C∂ )S
; otherwise, ° d ONLN d@ ö œ ¶ )=PrError ° d ONLN dG õ ßs )1 might still contain this ° d ONLN da õs ß∂ )serror the next ° d ONLN dp ß 7 ≥á ( œ UFtime you check it, which would prevent your application from printing.
° d ONLN d∑ À ⁄1 ( ˆ 6)Canceling or Pausing the Printing Process
° d ONLN d· Ê Ú ë *If you install a procedure ° d ONLN d¸ Ê ë Ú⁄ )yEfor handling requests to cancel printing, with an option to pause the ° d ONLN dB Ú ˛ ( 6-printing process, beware of timeout problems ° d ONLN do Ú ˛⁄ (:!when printing to the LaserWriter. ° d ONLN dí ˛
W (& 6=Communication between the Macintosh and the LaserWriter must ° d ONLN dœ ˛W
⁄ (&ube maintained to prevent a ° d ONLN dÍ
à (2 6^job or a wait timeout. If there is no communication for a period of time (over two minutes), ° d ONLN dH
Ã⁄ (2Íthe ° d ONLN dL "° (> 6Yprinter times out and the print job terminates due to a wait timeout. Or, if the print ° d ONLN d•°"⁄ (>ø job requires ° d ONLN d≤" . µ (J 6"more than three minutes to print, ° d ONLN d‘" µ.⁄ )ù?the print job terminates due to a job timeout. Since, there is ° d ONLN d. : Ô (V 6,no good method to determine to what type of ° d ONLN d@. Ô:⁄ )◊4printer an application is printing, it is probably a ° d ONLN du: Få (b 6Mgood idea to document the possibility of a LaserWriter timing out for a user ° d ONLN d¬:åF⁄ (b™who chooses to ° d ONLN d—F R ƒ (n 6$select “pause” for over two minutes.
° d ONLN dˆj y' *'%Error Messages Created In Print Land…
$and terminates the printing loop, if ° d ONLN d,™ ∂# (“ 67necessary. As already documented, if you encounter an ° d ONLN dc™#∂⁄ (“A'error in the middle of a printing loop, ° d ONLN dã∂ ¬Æ (fi 6Wdo not jump out; fall through the loop and let the Printing Manager terminate properly. ° d ONLN d„Œ <⁄ { +$
Error Code ° d ONLN dÓŒ Ñ⁄ ∂ )HConstant ° d ONLN d˜Œ ⁄1 )l Description ˘ X˘ñ ° d ONLN d‹ ZË ` ( x0 ° d ONLN d€ ÑÁ ß )*noErr ° d ONLN d ‹ Ë )lNo error ° d ONLN dÈ Nı ` ( l128 ° d ONLN dË ÑÙ º )6iPrAbort ° d ONLN d#È ık )lAbort the printing process ° d ONLN dBı K * (Command-period) ° d ONLN dT V ` (* t-1 ° d ONLN dW Ñ
— ). iPrSavePFil ° d ONLN dc e )lProblem saving print file ° d ONLN d~ P ` (7 n-17 ° d ONLN dÇ Ñ )4
of 11 (÷Z#PR 10 - A Printing Loop That Cares… +YM.PR.PrintLoop ˇ÷ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ê October 1990 / X /
° d ONLN d ) < 5R ( Q Z<The following errors are specific to the LaserWriter family: ° d ONLN d > B h N Ñ +,-4101 ° d ONLN d E B Nì )¨Printer not found or closed ` | ` ° d ONLN d b N h Z Ñ ( v Ü-4100 ° d ONLN d i N Z )¨Connection just closed ° d ONLN d Å Z h f Ñ ( Ç Ü-4099 ° d ONLN d à Z fw )¨Write request too big ° d ONLN d ü f h r Ñ ( é Ü-4098 ° d ONLN d ¶ f r} )¨Request already active ° d ONLN d æ r h ~ Ñ ( ö Ü-4097 ° d ONLN d ≈ r ~Ç )¨Bad connection refnum ° d ONLN d ‹ ~ h ä Ñ ( ¶ Ü-4096 ° d ONLN d „ ~ ä¨ )¨No free Connect Control ° d ONLN d ˚ ~¨ ä˛ )ò
Blocks (CCBs) ° d ONLN d ä ñ= ( ≤2 available ° d ONLN d ñ h ¢ Ñ ( æ Ü-8133 ° d ONLN d ñ ¢Ù )¨.PostScript error occurred during transmission ° d ONLN dI ñÙ ¢˛ )‡of ° d ONLN dL ¢ Æ ( 20data to printer. Most often caused by a bug in ° d ONLN d| ¢ Æ˛ )‹the ° d ONLN dÄ Æ ∫º ( ÷2!PostScript code being downloaded. ° d ONLN d£ ∫ h Δ Ñ ( ‚ Ü-8132 ° d ONLN d™ ∫ Δp )¨Timeout occurred. ° d ONLN dº ∫p Δ˛ )\ This error is returned when ° d ONLN dŸ Δ “U ( Ó2 no data has ° d ONLN d ΔU “˛ )A been sent to the printer for two ° d ONLN d “ fiw ( ˙2minutes. Usually ° d ONLN d “w fi˛ )ccaused by extremely long ° d ONLN d1 fi ÍU (2
imaging time. ° d ONLN d@ Í h ˆ Ñ ( Ü-8131 ° d ONLN dG Í ˆ7 )¨Printer ° d ONLN dO Í7 ˆ˛ )#(not responding: it may have been turned ° d ONLN dx ˆQ ( 2
“off.” This ° d ONLN dÖ ˆQ˛ )=$error occurs if a user turns off the ° d ONLN d™– (*2)LaserWriter in the middle of a print job. - |- ° d ONLN d‘( <4 Â (P Z%The following errors are specific to ,
Requested ° d ONLN dNNRZë )> PrGeneral ° d ONLN dWOë[fi )? opcode not ° d ONLN dc[g÷ (É2*implemented in the current printer driver. ° d ONLN dèh nt Ñ (ê å-192 ° d ONLN dîg ®s ı ): resNotfound ° d ONLN d†htß )l The current printer driver does ° d ONLN d¿hßtfi )ì not support ° d ONLN dÃtÄS (ù2 PrGeneral ° d ONLN d’uSÅW )?. † |†˝ ° d ONLN d◊ö <¶’ (¬ ZTThe most common error encountered is -4101, which is generated if no LaserWriter is ° d ONLN d+ö’¶˛ (¬Û selected. ° d ONLN d6¶ <≤ † (Œ ZSince this error is so ° d ONLN dM¶ †≤˛ )dHcommon, it is a good idea to display a dialog box requesting the user to ° d ONLN dñ≤ <æl (⁄ ZAselect a printer from the Chooser when this error is encountered. ° d ONLN dÿ‚ <Ó ¶ *0Further Reference:
X
° d ONLN dÎÔ N˚ R +
• ° d ONLN dÌÔ `˚ ± )Inside Macintosh ° d ONLN d˝Ô ±˚ô )Q-, Volume II-145 & V-410, The Printing Manager ° d ONLN d+˚ N R (# l• ° d ONLN d-˚ `" )$Technical Note M.IM.DevIndPrinting — ° d ONLN dT Ñ +$ Device-Independent Printing ° d ONLN dq N R (; l• ° d ONLN ds ` ó )
d e v e l o p ° d ONLN dÄ ó Q )7&, July 1990, Issue 3, “Meet PrGeneral” ¡ X¡
(÷ Z#PR 10 - A Printing Loop That Cares… (÷˙11 )
of 11 (Ï ZM.PR.PrintLoop ˇ‰ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å1
0Ià:µú9 " {( ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R◊ R… õr +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
*K ( {üDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f* f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 Ï ( U˚ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+( ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
ìõ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å{ ( õ Z%PR 11 - Programmatic PostScript Files
° d ONLN d & Ä < è s *Printing
° d ONLN d 0 õ < ß q * Written by: ° d ONLN d < õ Ñ ß )H Matt Deatherage & Hugo Ayala ° d ONLN d Y õ√ ß ( √·September 1992 ° d ONLN d h ≥ < ø ° ( € ZThis Technical Note ° d ONLN d | ≥ ° ø˛ )eEdiscusses how to make the LaserWriter driver, versions 7.0 and later, ° d ONLN d ¬ ø < À÷ ( Á ZYcreate PostScript files from your printing loop, and when this is and is not appropriate. ° d ONLN d ◊ < „ b *Topics ° d ONLN d# „ W Ô — + • Creating PostScript files ° d ONLN d? Ô W ˚x * ?• The LaserWriter driver is not a PostScript conversion utility ° d ONLN d ˚ Wi * ;• Sample functions for creating an appropriate print record 2 X2
° d ONLN dª, <; (W Z I get to make PostScript files?
° d ONLN d€G <S Ê *$Yes, but don’t get too excited yet. ° d ONLN dˇG ÊS˛ )™9 The feature we’re about to describe is not applicable in ° d ONLN d9S <_£ ({ ZIevery case where you might want to generate PostScript code, so it’s not ° d ONLN dÇS£_˛ ({¡a generic solution. ° d ONLN dó_ <k Ò (á Z&Like those standardized tests used to ° d ONLN dΩ_ Òk˛ )µ7say, “Please read all the directions before marking the ° d ONLN dık <w [ (ì Zpage.” ° d ONLN d¸É <èØ *OThere are definitely situations where forcing the LaserWriter driver to create ° d ONLN dKÉØè˛ (´Õa PostScript file ° d ONLN d]è <õ (∑ Z*has advantages. It’s extremely handy for ° d ONLN dáè õ˛ )Õ1many large, multi-network Macintosh installations ° d ONLN dπõ <ßÅ (√ ZCthat have unique printing needs. It can be handy for people using ° d ONLN d¸õÅ߲ (√ünon-AppleTalk PostScript ° d ONLN dß <≥û (œ ZPprinters. It’s a very useful capability in this and dozens of other situations. ° d ONLN dfø <À j *
What it’s ° d ONLN dpø jÀ | ).not ° d ONLN dsø |ÀL )- useful for is generic PostScript conversion. ° d ONLN d°◊ <„/ (ˇ Z2The LaserWriter driver was designed expressly for ° d ONLN d”◊/„˛ )Û)the purpose of converting QuickDraw calls ° d ONLN d˝„ <Ô† ( ZJto PostScript for high-resolution imaging on Apple’s PostScript printers. ° d ONLN dG„†Ô˛ ( æ As the years have ° d ONLN dZÔ <˚7 ( Z7gone by, it’s been adapted to things that weren’t part ° d ONLN dëÔ7˚˛ )˚*of the original design model (like driving ° d ONLN dº˚ <^ (# Z>non-Apple PostScript printers). One of the features added in ° d ONLN d˙˚^˛ (#|"recent years was the capability to ° d ONLN d <+ (/ Z0dump a PostScript file when printing. This was ° d ONLN dM+˛ )Ô+originally only a debugging feature for the ° d ONLN dy < (; Z,convenience of the engineers working on the ° d ONLN d• ˛ )÷0driver, but when it was made accessible to users ° d ONLN d÷ <+ Ú (G Z!through a hidden dialog item and ° d ONLN d˜ Ú+˛ )∂1a not-so-secret key combination, the response was ° d ONLN d)+ <7\ (S Z<overwhelming. In response, the printing engineers included ° d ONLN de+\7˛ (Sz#the capability to pick a PostScript ° d ONLN dâ7 <Cj (_ ZDfile for output was built into versions 7.0 and later of the driver. ° d ONLN dŒO <[ ‹ *!That didn’t change the fact that ° d ONLN dÔO ‹[˛ )†;it was still, at heart, a glorified debugging feature. The ° d ONLN d+[ <gé (É ZKPostScript the driver creates is designed expressly for printing. It does ° d ONLN dv[ég˛ (ɨnot create Encapsulated ° d ONLN dég <s s (è Z PostScript ° d ONLN dôg ss˛ )7Kfiles (EPSF format). It doesn’t easily incorporate any PostScript document ° d ONLN dÂs <N (õ Z<conventions other than the one it uses for its own benefit. ° d ONLN d !sN˛ (õl% It doesn’t generate PostScript Level ° d ONLN d G <ã V (ß Z2. It ° d ONLN d N Vã˛ )Sincludes large amounts of custom encrypted code to provide TrueType™ font rendering ° d ONLN d ¢ã <ó( (≥ Z1technology on PostScript printers where possible. ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5â *$MIt’s important to understand that you can’t change any of this. If you have ° d ONLN d M )â 5⁄ ( Qßa strong need to ° d ONLN d ^ 5 A´ ( ] 6Sprogrammatically create files just like the LaserWriter driver would create if you ° d ONLN d ± 5´ A⁄ ( ]… chose the ° d ONLN d ª A MW ( i 6H“PostScript file” radio button in the job dialog, this technique is for ° d ONLN d AW M⁄ ( iuyou. If you need anything ° d ONLN d M Yy ( u 6Lmore customizable, or more specialized, or in a different format, this Note ° d ONLN dj My Y⁄ ( uóis not for you. The ° d ONLN d Y e Ä ( Å 6LaserWriter driver is ° d ONLN dï Y Ä e⁄ )hFnot and never has been a generic PostScript conversion utility; if you ° d ONLN d‹ e qc ( ç 6Hwant such capabilities, you must still build them into your application.
Ω å … ß )1 , a ° d ONLN d º ß » )dirID ° d ONLN d Ω … Ú )# and a ° d ONLN d Ω Ú … )(pointer ° d ONLN d% Ω … )! ° d ONLN d& Ω …⁄ )%to the file name—all inside a private ° d ONLN dL … ’ ü ( Ò 6 LaserWriter driver structure. ° d ONLN dj · Ì p *The flag is a bit in ° d ONLN d · p Ì⁄ )XMthe word starting at offset $52 (or 82 decimal) of the print record. This is ° d ONLN dÕ Ó ˙ c ( 6documented as ° d ONLN d€ Ó c ˙ ´ )Kboolean value ° d ONLN dÈ Ì ´ ˘ π )Hf2 ° d ONLN dÎ Ó π ˙C ) of the printer flags record ° d ONLN d ÌC ˘t )äprFlag1 ° d ONLN d Ót ˙⁄ )1. Figure 1 shows a ° d ONLN d# ˚ (# 67redeclaration of this record with the newly-documented ° d ONLN dZ ˙ P (#=fPSFile ° d ONLN da ˚Pé )1 bit included. "2 3 # 2 42! "2" # "3 3 "3"
° d ONLN dΩÈ èıb +w"!Figure 1—Redefined PrFlag1 Record ° d ONLN dfl (6 6/Note that the record is renamed beginning with ° d ONLN d
)lw ° d ONLN d) ) to ° d ONLN d)¡ ) emphasize that this technique ° d ONLN d2¡⁄ )òonly ° d ONLN d7 & (B 61works with the LaserWriter driver. This means ° d ONLN dh&⁄ )Í-you have to check that you’re printing to the ° d ONLN dñ' 3 S (O 6 LaserWriter ° d ONLN d¢' S3 );'driver by making sure the high byte of ° d ONLN d…&2` )¿ TPRStl.wDev ° d ONLN d‘'`3⁄ )M is 3, for the LaserWriter ° d ONLN dÔ3 ? d ([ 6driver. If other ° d ONLN d3 d?⁄ )LKdrivers impersonate the LaserWriter driver (which they may do, for example, ° d ONLN dM? Kü (g 6Jso that your application sends them PostScript in picture comments), this ° d ONLN dó?üK∂ (gΩmay ° d ONLN dö?∂KΩ ) ° d ONLN dõ?ΩK⁄ )crash. ° d ONLN d£K Wq (s 6LUnfortunately, Apple can’t conclusively tell you that a third-party printer ° d ONLN dÔKqW⁄ (sèdriver will or will not ° d ONLN d W c fi ( 6+support this feature. Apple’s driver does. ° d ONLN d 3o {ù *RWhere does the LaserWriter driver put the new PostScript file? The word starting ° d ONLN d Öoù{⁄ (óª
. +Z-Developer Support Center ( -€September 1992 / X /
° d ONLN d < ) ˙ ( E Z'pointer to the PostScript file name as ° d ONLN d ' ˙ )˛ )æ4a Pascal string—just the file name; the other fields ° d ONLN d \ ) < 5 › ( Q Z#indicate the other portions of the ° d ONLN d ) › 5˛ )°?file’s specification (in fact, they’re all three portions of an ,
if there’s ° d ONLN dê„ Ôb ( 6Dany chance the file name might not be unique when PrintMonitor gets ° d ONLN d‘„bÔ⁄ ( Äaround to despooling the ° d ONLN dÌÔ ˚ 3 ( 6file. ° d ONLN dÙÔ 3˚⁄ )WFurthermore, if you try to write over an existing file, the LaserWriter driver will not ° d ONLN d L˚ M (# 6 change the ° d ONLN d W˚ M⁄ )5Uend-of-file position, so the result file will have the larger EOF of the new file and ° d ONLN d ≠ º (/ 6$the old contents. This is also Bad. ° d ONLN d “ + Í *)Here’s a summary of what we’ve discussed: ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1992 / X /
° d ONLN d < ) F ( E Z1. ° d ONLN d N )> )5Get a print record ready to start your printing loop. ° d ONLN d 9 * < 6 F ( R Z2. ° d ONLN d < * N 6 Ü ) Change the ,
° d ONLN d% ≥ < ø *+The following System 7-only sample routine ° d ONLN dP ≤ æÄ )‚PrPSFileDialog ° d ONLN d^ ≥Ä øö )b can ° d ONLN dc ≥ö ø˛ )be used in place of ° d ONLN dw ø < À â ( Ë Z PrJobDialog ° d ONLN dÇ ¿ â à )M when using this technique. ° d ONLN dü ¿ Ã˛ )é/Note that the routine requires a handle of type ° d ONLN dœ à < ÿ { ( ı Z lwTHPrint ° d ONLN dÿ Õ { Ÿ )?. ° d ONLN d⁄  < Ò [ (
ZNote: ° d ONLN d‡ Â ` Ò Ù )$ Be careful about bypassing the ° d ONLN dˇ Â Ù Ò⁄ )î/job dialog. The LaserWriter driver resets some ° d ONLN d/ Ò ` ˝ ( ~other ° d ONLN d5 Ò ˝⁄ ) Cjob-specific parameters (besides the file to save PostScript in) in ° d ONLN dy ˝ ` ü (& ~ PrJobMain ° d ONLN dÇ ˛ ü
µ )?. ° d ONLN dÖ ˛ µ
⁄ )4If you save a print record immediately after calling ° d ONLN d∫
` ≠ (3 ~ PrJobDialog ° d ONLN d≈ ≠ ◊ )M and use ° d ONLN dŒ ◊⁄ )*6that print record without going through the job dialog ° d ONLN d `# Å (? ~again, ° d ONLN d Å# è )!all ° d ONLN d è#| )2 of the job-specific parameters will be preserved ° d ONLN dA|#⁄ )Ì(number of copies, ° d ONLN dT# `/® (K ~Epage range, feeder choice, etc.). This may not be what you intended.
° d ONLN dö; <FY (b Z9FUNCTION PrPSFileDialog(thePrRecHdl: lwTHPrint): BOOLEAN; ° d ONLN d‘Q <\ Z * VAR ° d ONLN d€[ <f Ê *
" ourReply: StandardFileReply; ° d ONLN d˛e <p π *
tempFlags: INTEGER; ° d ONLN do <z æ *
tempResult: BOOLEAN; ° d ONLN d3y <Ñ ¥ *
ourOSError: OSErr; ° d ONLN dLÉ <é õ *
tempPtr: Ptr; ° d ONLN d`ó <¢ d * BEGIN ° d ONLN di° <¨E *
5 PrPSFileDialog := FALSE; { being conservative } ° d ONLN dü´ <∂E *
5 tempResult := PrValidate(THPrint(thePrRecHdl)); ° d ONLN d’ø < ' */ IF NOT thePrRecHdl^^.prFlag1.fPSFile THEN ° d ONLN d… <‘r *
> { don't do this if there's already a file to be saved! } ° d ONLN dD” <fi Ç *
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN dˇˇ ( õ Z PR 12 - SetLineWidth Revealed
° d ONLN dˇˇ *Printing
° d ONLN dˇˇ * Revised by: ° d ONLN dˇˇ ( √„
March 1988 ° d ONLN dˇˇ ( œ Z Written by: ° d ONLN dˇˇ )HScott "ZZ" Zimmerman ° d ONLN dˇˇ ( œœ
November 1987 ° d ONLN dˇˇ ( Á ZQThis technical note describes the internal implementation, and correct method of ° d ONLN dˇˇ ( ÁÍ
using, the ,
Courier ° d ONLN dˇˇ ( Ù Z SetLineWidth ° d ONLN dˇˇ )T Picture Comment. X ° d ONLN dˇˇ ( ZThe ° d ONLN dˇˇ ) SetLineWidth ° d ONLN dˇˇ )T picture comment provides ° d ONLN dˇˇ )ú a way of accessing PostScript’s ° d ONLN dˇˇ (& Z#'setlinewidth' operator. Since the ° d ONLN dˇˇ )®8LaserWriter resolution is roughly four times that of the ° d ONLN dˇˇ (3 Z Macintosh screen, fractional ° d ONLN dˇˇ )ã line widths can be printed. The ° d ONLN dˇˇ )° SetLineWidth ° d ONLN dˇˇ )T PicComment ° d ONLN dˇˇ (? Zprovides a way for ° d ONLN dˇˇ )dGapplications to access these fractional line widths through PostScript, ° d ONLN dˇˇ (K Z-without having to use floating point numbers. ° d ONLN dˇˇ *4First of all, the LaserWriter has an internal state ° d ONLN dˇˇ )ı(that is stored in a number of PostScript ° d ONLN dˇˇ (o Zvariables. For more ° d ONLN dˇˇ )l-information on PostScript variables, see the ° d ONLN dˇˇ )ÔPostScript Language ° d ONLN dˇˇ ({ ZReference Manual ° d ONLN dˇˇ )V#. Some operations performed on the ° d ONLN dˇˇ )≥%LaserWriter cause the values of these ° d ONLN dˇˇ (á ZUvariables to change. One of these variables contains the width of the printer’s pen. ° d ONLN dˇˇ (á
The ° d ONLN dˇˇ (î Z SetLineWidth ° d ONLN dˇˇ )T> picture comment works by changing the value of this variable. ° d ONLN dˇˇ (≠ ZBefore we look at what the ° d ONLN dˇˇ )Ç SetLineWidth ° d ONLN dˇˇ )T comment does, let’s ° d ONLN dˇˇ )elook at the argument passed ° d ONLN dˇˇ (π Zto the comment. ° d ONLN dˇˇ )OKThe argument is represented as a QuickDraw Point, however it is interpreted ° d ONLN dˇˇ (Δ Z"by the LaserWriter as a fraction. ° d ONLN dˇˇ )ß The LaserWriter interprets a ° d ONLN dˇˇ )ì
point(h,v) ° d ONLN dˇˇ )F
to be a real ° d ONLN dˇˇ (” Znumber whose value is ° d ONLN dˇˇ )p(v ° d ONLN dˇˇ )/ h) ° d ONLN dˇˇ ) :. This means that a point whose value is h=2, v=1, will be ° d ONLN dˇˇ (fl Z7converted to 0.5 before being used by the LaserWriter. ° d ONLN dˇˇ (fl`&If you wanted to pass a value of 0.25, ° d ONLN dˇˇ (Î ZRyou would pass a point whose value is h=4, v=1. For 1.25, pass a point, h=4, v= 5. ° d ONLN dˇˇ *TIn addition to the pen width variable, there is a variable that is used for scaling ° d ONLN dˇˇ (Õthe pen’s width. ° d ONLN dˇˇ ( ZThis variable, named ° d ONLN dˇˇ )ipnm ° d ONLN dˇˇ )@ for PeN Multiplier, contains a real number which is applied to ° d ONLN dˇˇ (the ° d ONLN dˇˇ ( Z pen width. The default value of ° d ONLN dˇˇ )ópnm ° d ONLN dˇˇ )3 is 1.0, which causes no scaling of the line width. ° d ONLN dˇˇ (6 Z
Whenever the ° d ONLN dˇˇ )F SetLineWidth ° d ONLN dˇˇ )T( PicComment is sent to the LaserWriter, ° d ONLN dˇˇ )«the current value of ° d ONLN dˇˇ (C Zpnm ° d ONLN dˇˇ )@ is replaced by the value passed to the PicComment. The current ° d ONLN dˇˇ (C†pen size is then scaled by ° d ONLN dˇˇ (P Zthe new value of ° d ONLN dˇˇ )Upnm ° d ONLN dˇˇ )3. The following example will display four lines of ° d ONLN dˇˇ )˜different sizes. It is ° d ONLN dˇˇ (] Zmeant ° d ONLN dˇˇ )"4to illustrate the interaction between the QuickDraw ° d ONLN dˇˇ (]àPenSize ° d ONLN dˇˇ )1 procedure and the ° d ONLN dˇˇ (j Z SetLineWidth ° d ONLN dˇˇ )T PicComment.
° d ONLN dˇˇ (Å ZTYPE ° d ONLN dˇˇ +$
widthHdl = ^widthPtr; ° d ONLN dˇˇ *
widthPtr = ^widthPt; ° d ONLN dˇˇ *
widthPt = Point; ¡ X¡
(÷ Z PR 12 - SetLineWidth Revealed (÷1 ) of 4 (Ï ZM.PR.SetLineWidth ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø2 ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( ' *VAR ° d ONLN d ' 2 ï *
theWidth: widthHdl; ° d ONLN d ; F 1 *BEGIN ° d ONLN d % O < Z ˇ +$'(* Initialize the print manager as per ° d ONLN d L O ˇ ZO )√Inside Macintosh ° d ONLN d \ OO ZÜ )P II-155. *)
° d ONLN d h f r ≠ ( é 6"At this point, it is assumed that ° d ONLN d ä e ≠ q Û )ï
PrPageOpen ° d ONLN d î f Û r ˆ )F ° d ONLN d ï f ˆ r⁄ )/has been called, and the print manager is ready ° d ONLN d ≈ r ~ [ ( ö 6to accept data. ° d ONLN d ’ ä ñ - *The ° d ONLN d Ÿ ä - ñ⁄ )Zfirst thing we do is set the scaling factor to 1.0. This way, no scaling will be performed ° d ONLN d4 ó £ Y ( ø 6
when we call ° d ONLN dA ñ Y ¢ ä )APenSize ° d ONLN dH ó ä £ é )1.
° d ONLN dK Ø < ∫1 ( ÷ Z1theWidth := widthHdl(NewHandle(SizeOf(widthPt))); ° d ONLN d~ π < ƒ *
,(*Real programs do error checking here... *) ° d ONLN d¨ √ < Œ ¥ *
° d ONLN d ‰ E ( 6Here we ° d ONLN d ‰ E Z )-call ° d ONLN d „ Z Ô ã )PenSize ° d ONLN d ‰ ã ” )1. Because the ° d ONLN d% „ ” Ô Ë )Hpnm ° d ONLN d( ‰ Ë ⁄ )1 has been set to 1.0, the pen size(1,1) times the ° d ONLN dZ ¸ ñ ( 6 multiplier (1.0) yields 1,1.
° d ONLN dx < Ç +$PenSize(1, 1); ° d ONLN dà < å *
MoveTo(50, 100); ° d ONLN dö <' ë *
LineTo(500, 100); ° d ONLN d≠& <1 å *
MoveTo(50, 125); ° d ONLN dø0 <; · *
!DrawString('1 point thickness.');
° d ONLN d·G S Ç (o 6Now we will use the ° d ONLN dıF ÇR ÷ )j SetLineWidth ° d ONLN dG ÷Sé )T$ PicComment to change the pen size. ° d ONLN d%GéS⁄ )∏Note that when ° d ONLN d4S _, ({ 6;we change the scaling factor, the pen size changes as well.
° d ONLN dqk <v ¥ +$SetPt(theWidth^^, 1, 5); ° d ONLN dãu <Äh *
<PicComment(SetLineWidth, SIZEOF(widthPt), Handle(theWidth)); ° d ONLN d… <ä å *
MoveTo(50, 200); ° d ONLN d€â <î ë *
LineTo(500, 200); ° d ONLN dÓì <û å *
MoveTo(50, 225); ° d ONLN d ù <®r *
>DrawString('5.0 times 1 point pen size = 5 point thickness.');
° d ONLN d?¥ ¿ [ (‹ 6If any calls to ° d ONLN dO≥ [ø å )CPenSize ° d ONLN dV¥ å¿K )1* are made at this point, the new pen size ° d ONLN dÄ¥K¿⁄ )ø will be scaled by 5.0. This is ° d ONLN dü¡ Õ ] (È 6 because the ° d ONLN d´¿ ]à ± )E SetLineWidth ° d ONLN d∑¡ ±Õ’ )T1 PicComment is still in effect. We will now send ° d ONLN dË¡’Õ⁄ (ÈÛa ° d ONLN dÍÕ Ÿ l (ˆ 6 SetLineWidth ° d ONLN dˆŒ l⁄e )T5 PicComment to revert the scaling factor back to 1.0.
° d ONLN d,Ê Ò § (
6 SetPt(theWidth^^, 5, 1); ° d ONLN dI ˚X *
@ PicComment(SetLineWidth, SIZEOF(widthPt), Handle(theWidth)); ° d ONLN dä˙ | *
MoveTo(50, 300); ° d ONLN dü | *
LineTo(500,300); ° d ONLN dµ | *
MoveTo(50, 325); ° d ONLN d #b *
B DrawString('0.2 times 5 point pen size = 1 point thickness.');
° d ONLN d
/ ; » *%Since the scaling is once again 1.0, ° d ONLN d2. »: ˘ )∞PenSize ° d ONLN d9/ ˘;∞ )1) calls at this point will not be scaled. ° d ONLN db/∞;⁄ )∑Here we ° d ONLN dj; G » (c 6)explicitly set the scaling factor to 1.0 ° d ONLN dì; »G⁄ )∞9before changing the pen size. This makes it easier to see ° d ONLN dÕH T Ò (p 61what scaling will be applied to the next call to ° d ONLN d˛G ÒS" )ŸPenSize ° d ONLN dH"T& )1.
° d ONLN d` k § (á 6 SetPt(theWidth^^, 1, 1); ° d ONLN d$j uX *
@ PicComment(SetLineWidth, SIZEOF(widthPt), Handle(theWidth)); ° d ONLN det r *
IR ° d ONLN d ıf <rp (é Z5To summarize, there are four things to remember when ° d ONLN d*fpr™ (éé
using the ° d ONLN d4e™q˛ ): SetLineWidth ° d ONLN dAr <~ | (ö Z PicComment: ° d ONLN dMã <ó F *1. ° d ONLN dPã Nó ° )The argument to ° d ONLN d`ã °ó ¥ )Sthe ° d ONLN ddä ¥ñ ) SetLineWidth ° d ONLN dpãó˛ )T1 PicComment is specified as a point, though it is ° d ONLN d¢ó N£
(ø l(actually interpreted by the LaserWriter ° d ONLN d ó
Z3. ° d ONLN d≠‚ NÓ û )When you send ° d ONLN dª‚ ûÓ ± )Pthe ° d ONLN dø· ±Ì ) SetLineWidth ° d ONLN dÀ‚Ó˛ )T1 PicComment, the current pen size will be scaled. ° d ONLN d˝Ó N˙E ( l1Any drawing that is done after the PicComment is ° d ONLN d.ÓE˙˛ )˜%set, will be done with the scaled pen ° d ONLN dT˙ N d (" lsize. ° d ONLN dZ < F (; Z4. ° d ONLN d] N fl ) When you call the QuickDraw ° d ONLN dy fl )ëPenSize ° d ONLN dÄ Z )1 procedure, the ° d ONLN dêZ ˛ )J$pen size will be scaled after it has ° d ONLN dµ N+ú (G lFbeen set. For example, if your scaling factor is 0.5, and you set the ° d ONLN d˚ ú+˛ (G∫pen size to 2,2, the ° d ONLN d+ N7/ (S l/actual pen size will be 1,1. If you don’t want ° d ONLN d@+/7˛ )·)the scaling to occur, make sure to send a ° d ONLN dk7 NC ¢ (` l SetLineWidth ° d ONLN dw8 ¢D )T PicComment, with ° d ONLN dâ8D˛ )e0the point argument set to 1,1. The next call to ° d ONLN d∫D NP (m lPenSize ° d ONLN d¡E Q} )17 will then be scaled by 1.0, which will have no effect. ¡ X¡
(÷ Z PR 12 - SetLineWidth Revealed (÷3 ) of 4 (Ï ZM.PR.SetLineWidth ˇ, ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) Ç *Further Reference: H 4 H˘ ° d ONLN d * * 6 . +
• ° d ONLN d * < 6 à ) LaserWriter Reference Manual ° d ONLN d 2 6 * B . ( ^ H• ° d ONLN d 4 6 < B ˆ )$PostScript Language Reference Manual ° d ONLN d Y B * N . ( j H• ° d ONLN d [ B < N ))PostScript Language Tutorial and Cookbook ¡ 4¡˘
(÷ 64 ) of 4 (÷x PR 12 - SetLineWidth Revealed +-M.PR.SetLineWidth ˇæ ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç ( ú ZPR 13 - Spooler Queries?
° d ONLN d Å < ê s *Printing
° d ONLN d # ú < ® t * Revised by: ° d ONLN d 0 ú≈ ®˛ ( ƒ„
March 1988 ° d ONLN d ; ® < ¥ q ( – Z Written by: ° d ONLN d G ® Ñ ¥ – )HGinger Jernigan ° d ONLN d W ®œ ¥˛ ( –Ì July 1987 fl X fl ° d ONLN d a Õ < Ÿ ( ı Z%When the LaserShare spooler is on an ° d ONLN d Ü Õ Ÿ˛ )ƒ2AppleTalk network, it acts like a LaserWriter-type ° d ONLN d π Ÿ < Âh ( Z7device, which can be chosen and communicated with much ° d ONLN d Ÿh ² (Ü like a real LaserWriter. Some ° d ONLN d  < Ò (
Z-applications, however, must communicate with ° d ONLN d; Â Ò˛ )‚1a LaserWriter directly, not a spooler. If this is ° d ONLN dm Ò < ˝ ( Z true for your application, you ° d ONLN då Ò ˝˛ )é@can check whether you are actually talking to a real LaserWriter ° d ONLN dÕ ˝ < + (% Z2by sending to the LaserWriter the following query: ,
Courier
° d ONLN d `! ƒ +$%!PS-Adobe-1.2 Query ° d ONLN d `+< *
,%%Title: Query to Spooler/Non-Spooler status ° d ONLN dE* `5 ƒ *
%%?BeginSpoolerQuery ° d ONLN d[4 `? ó *
(0) = flush ° d ONLN dh> `I ƒ *
%%?EndSpoolerQuery 1 ° d ONLN d~H `S y *
%%EOF
° d ONLN dÑ^ <jê (Ü ZG(The query has to be sent using the Printer Access Protocol (PAP). The ° d ONLN dÀ^êj˛ (ÜÆobject code for PAP is ° d ONLN d‚j <vπ (í ZPavailable from Licensing.) If the string returned begins with a ‘%%’ then it is ° d ONLN d2jπv˛ (í◊a status string ° d ONLN dBv <Çñ (û ZIand you can ignore it and wait for another string. If the LaserWriter is ° d ONLN dãvñDz (û¥actually a LaserShare ° d ONLN d°Ç <éÑ (™ ZJspooler, then the string that is returned will be ‘1’. If the LaserWriter ° d ONLN dÎÇÑé˛ (™¢is a real LaserWriter then ° d ONLN dé <ö (∂ Z the string returned will be ‘0’. ° d ONLN d'æ < ¶ *0Further Reference: È XÈ ° d ONLN d:À N◊ R +
• ° d ONLN d<À `◊ )$PostScript Language Reference Manual ° d ONLN da◊ N„ R (ˇ l• ° d ONLN dc◊ `„T ).Adobe Systems Document Structuring Conventions ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø$ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < ÅK ( õ Z PR 14 - Dictionary Downloading
° d ONLN d Ä < è s *Printing
° d ONLN d ) õ < ß q * Written by: ° d ONLN d 5 õ Ñ ß Ã )H Zz Zimmerman ° d ONLN d B õÀ ߲ ( √È
April 1991 ° d ONLN d M ≥ < øO ( € Z7This technical note discusses a method for downloading ° d ONLN d Ñ ≥O ø˛ ( €m%PostScript dictionaries automatically ° d ONLN d ™ ø < À · ( Á Z"using the LaserWriter driver. It ° d ONLN d à ø · À˛ )•5will also provide the format and use of the PREC(103) ° d ONLN d À < ◊0 ( Û Z4resource. It will also describe some problems with ° d ONLN d6 À0 ◊˛ )Ù(the now obsolete PREC(201) resource. If ° d ONLN d_ ◊ < „Í ( ˇ Z[you are using PostScript dictionaries, or either of these resources, you should definitely ° d ONLN d∫ ◊Í „˛ ( ˇread ° d ONLN dø „ < Ô h ( Z
this note. X
° d ONLN d <# è *4 Introduction
° d ONLN d◊/ <; *ZAlthough many picture comments have been added to support the features of PostScript that ° d ONLN d1/;˛ (Ware ° d ONLN d5; <GU (c Z9missing from Quickdraw, many developers have still taken ° d ONLN dn;UG˛ (cs#to sending PostScript directly from ° d ONLN díG <Sµ (o ZRtheir applications. As the use and complexity of this PostScript code increases, ° d ONLN d‰GµS˛ (o”
more and more ° d ONLN dÚS <_ Ò ({ Z$developers are finding it necessary ° d ONLN dS Ò_˛ )µ4to define and use their own PostScript dictionaries. ° d ONLN dL_ <kÛ (á ZWPostScript dictionaries are basically collections of variables and procedures that can ° d ONLN d£_Ûk˛ (ábe ° d ONLN d¶k <w u (ì Z predefined, ° d ONLN d≤k uw˛ )9Pand accessed later. They are used to prevent conflicts between the symbols used ° d ONLN dw <Éi (ü Z?by applications and those used by system software (such as the ° d ONLN dBwiɲ (üá LaserWriter driver's LaserPrep ° d ONLN daÉ <èJ (´ Z8dictionary). Unfortunately, because of the LaserWriter ° d ONLN dôÉJè˛ (´h%drivers habit of using the PostScript ° d ONLN døè <õ§ (∑ ZM'save' and 'restore' operators, there are problems with keeping a PostScript ° d ONLN d è§õ˛ (∑¬dictionary defined. ° d ONLN d!õ <ß% (√ Z.PostScript definitions made by code sent with ° d ONLN dOõ%߲ )È,the print job (ie. sent between the calls to ° d ONLN d|ß <≥ (œ Z)PrOpenPage/PrClosePage) will be lost the ° d ONLN d•ß≥˛ )‘2first time the LaserWriter driver calls 'restore'. ° d ONLN dŸ≥ <øO (€ Z9There are a couple of solutions to this problem, but one ° d ONLN d≥Oø˛ (€m"that hasn't been documented before ° d ONLN d5ø <Àß (Á ZMinvolves the use of the PREC(103) resource. If the LaserWriter driver finds ° d ONLN dÇøßÀ˛ (Á≈a resource of type ° d ONLN dïÀ <◊ w (Û Z
PREC with ° d ONLN düÀ w◊⁄ );Fan ID of 103, it will download the PostScript code to the LaserWriter ° d ONLN dÂÀ⁄◊˛ (Û¯before ° d ONLN dÏ◊ <„é (ˇ ZJperforming the initial 'save' operation. This means that any definitions ° d ONLN d6◊鄲 (ˇ¨made by the PostScript ° d ONLN dM„ <ÔÆ ( ZKcode stored in the PREC(103) resource will remain defined for the duration ° d ONLN dò„ÆÔ˛ ( Ãof the print job, ° d ONLN d™Ô <˚m ( ZBindependent of the LaserWriter driver's calls to save and restore.
° d ONLN dÌ <" n *'Caveats
° d ONLN dı. <:Ê *LThe PREC(103) method is a great way to get a dictionary downloaded at print ° d ONLN dA.Ê:˛ (Vtime. ° d ONLN dH: <F, (b Z3Unfortunately, this does not solve the problem for ° d ONLN d{:,F˛ )-using dictionaries in export files like PICT. ° d ONLN d™F <R” (n ZVIf you insert PostScript code into Quickdraw pictures, the system is not smart enough ° d ONLN d F”R˛ (nÒ to record ° d ONLN d
R <^ æ (z Zthe PREC(103) code into ° d ONLN d "R æ^˛ )Ç?the picture. Instead, you must record the dictionary using the ° d ONLN d b^ <j ƒ (Ü Z standard PostScript picture ° d ONLN d ~^ ƒj˛ )à;comments (defined in Technical Note #91, Optimizing for the ° d ONLN d ∫j <v Í (í Z LaserWriter–PicComments). You ° d ONLN d Ÿj Ív˛ )Æ6should also use the appropriate PostScript structuring ° d ONLN d
v <Ç ¬ (û Zcomments as defined by the ° d ONLN d
+v ¬ÇO )ÜAdobe Document Structuring ° d ONLN d
FvOÇã )ç Conventions ° d ONLN d
QvãDz )<. If you use the Adobe ° d ONLN d
iÇ <é £ (™ Zcomments correctly, ° d ONLN d
}Ç £é˛ )gEan application that is importing your picture will have the option of ¡ X¡
(÷ Z PR 14 - Dictionary Downloading (÷1 ) of 3 (Ï ZM.PR.DictionaryDownoading ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ¯ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )/ *;parsing for the procedure set comments, and extracting the ° d ONLN d ; / )⁄ ( EM%dictionary definition to be placed in ° d ONLN d a ) 5 ¬ ( Q 6#a PREC(103) resource at print time. ° d ONLN d Ö A M D * The next ° d ONLN d é A D M⁄ ),Pcaveat concerns the use of multiple PREC(103) resources. At PrOpenDoc time, the ° d ONLN d fl M Y Á ( u 6)LaserWriter driver makes one GetResource ° d ONLN d M Á Y⁄ )œ1call to load the resource of type PREC with an ID ° d ONLN d: Y eó ( Å 6Oof 103. Because the call is a GetResource call (instead of Get1Resource), the ° d ONLN dâ Yó e⁄ ( ŵ PREC can be ° d ONLN dï e q r ( ç 6stored in any open ° d ONLN d® e r q⁄ )ZLresource file. To avoid any conflicts, the resource should be stored in the ° d ONLN dı q } \ ( ô 6resource fork ° d ONLN d q \ }⁄ )DOof your application, or in the document file that is referencing the PostScript ° d ONLN dS } â — ( • 6%dictionary. Because the GetResource ° d ONLN dx } — â⁄ )π4call is only made once, only the first PREC resource ° d ONLN d≠ â ï Ë ( ± 6(found by GetResource will be used. Any ° d ONLN d’ â Ë ï⁄ )–.other PREC(103) resources will be ignored. As ° d ONLN d ï ° z ( Ω 6long is this resource ° d ONLN d ï z °⁄ )bIis only used by applications, there is no problem since there can only be ° d ONLN dd ° ≠Ω ( … 6Zone application active at any particular time. If the resource is used by other elements ° d ONLN dæ °Ω ≠⁄ ( …€of the ° d ONLN d≈ ≠ π Q ( ’ 6 system (ie. ° d ONLN d— ≠ Q π⁄ )9Ndesk accessories, drivers, INITs), you can easily run into the problem of your ° d ONLN d π ≈ä ( · 6KPREC resource being ignored. The best solution to this problem is to only ° d ONLN dk πä ≈⁄ ( ·®use the resource ° d ONLN d| ≈ — ò ( Ì 6from within an application. ° d ONLN dò › È F *
Since the ° d ONLN d¢ › F È⁄ ).TPREC(103) resource is considered part of the print job, the definitions it makes are ° d ONLN d˜ È ı K ( 6
lost when ° d ONLN d È K ı⁄ )3Nthe job ends (ie. when the LaserWriter receives EndOfFile from the Macintosh). ° d ONLN dQ ı O ( 6>Because of this, the code you place in the PREC(103) resource ° d ONLN dè ıO⁄ ( mshould not attempt changing ° d ONLN d´
l () 6Bany persistent parameters in the printer. The means avoiding the ° d ONLN dÌl
⁄ ()äPostScript 'exitserver' ° d ONLN d
(5 68operator. You should also avoid calling other routines ° d ONLN d=
⁄ (5:+that reset the current state of the printer ° d ONLN di %R (A 6H(ie. initclip, initgraphics, etc.). Use of these operators will have a ° d ONLN d±R%⁄ (Apserious effect on Quickdraw ° d ONLN dÕ% 1 Û (M 60operations that may be present in the print job. ° d ONLN d˛= Iû *NWhen the PREC(103) resource was originally introduced, it had a cousin called ° d ONLN dL=ûI⁄ (eº
PREC(201). ° d ONLN dXI U ∏ (q 6 PREC(201) was similar to the ° d ONLN duI ∏U⁄ )†6PREC(103) resource in that it allowed PostScript to be ° d ONLN d¨U a≠ (} 6Wdownloaded to the printer before the actual print job. The difference between the two ° d ONLN dU≠a⁄ (}À resources ° d ONLN d
äµ ¡ƒ (› 6\remained after the job that required it, subsequent jobs had less memory available to them. ° d ONLN d
ʵƒ¡⁄ (›‚ The ° d ONLN d
Ρ Õ G (È 6 only way ° d ONLN d
Ù¡ GÕ⁄ )/Rto reclaim the memory was to reboot the printer, and this was not obvious to naive ° d ONLN d GÕ Ÿ P (ı 6 users. The ° d ONLN d SÕ PŸ⁄ )8Mother problem was introduced when background printing became available. With ° d ONLN d °Ÿ Â Ú ( 6-background printing enabled, the LaserWriter ° d ONLN d ŒŸ ÚÂ⁄ )⁄-driver could no longer count on the PREC(201) ° d ONLN d ¸Â Ò ¿ (
6!resource always being available. ° d ONLN d  ¿Ò⁄ )®4 Since you could no longer store the resource in the ° d ONLN d RÒ ˝ U ( 6 LaserWriter ° d ONLN d ^Ò U˝⁄ )=Ldriver (because of the LaserWriter driver being MultiFinder compatible - see ° d ONLN d ´˝ o (% 6Learning To Drive ° d ONLN d º˝ o r )W ° d ONLN d Ω˝ r ⁄ )Mfor more information), it has to be stored in a separate resource file. This ° d ONLN d
« (1 6Umade it virtually impossible for the LaserWriter driver to find the resource when it ° d ONLN d
` «⁄ (1Âwas ° d ONLN d
d ! G (= 6
required. ° d ONLN d
n G!⁄ )/K For this reason, the PREC(201) resource is only downloaded when background ° d ONLN d
° d ONLN d P < \ **The PREC(103) resource can be implemented ° d ONLN d 9 P \˛ )€/by simply creating the resource with ResEdit or ° d ONLN d i \ < h È ( Ñ Z$Rez, and then storing it in an open ° d ONLN d ç \ È h˛ )≠9resource file at print time. In the case of ResEdit, you ° d ONLN d « h < tÅ ( ê ZBshould create a new resource of type PREC with an ID of 103. You ° d ONLN d hÅ t˛ ( êüshould then open the new ° d ONLN d" t < ÄÉ ( ú ZDresource using the resource template for string ('STR ') resources. ° d ONLN df tÉ Ä˛ ( ú° You can then type your ° d ONLN d~ Ä < å ( ® Z+PostScript code directly into the resource. ° d ONLN d™ ò < §Ë *TIf you would rather keep your PREC definition as a Rez source file with the rest of ° d ONLN d˛ òË §˛ ( ¿your ° d ONLN d § < ∞ d ( à Z project, ° d ONLN d § d ∞˛ )(Qyou can do this by simply defining the PREC resource type at the top of the file, ° d ONLN d^ ∞ < º‡ ( ÿ ZVfollowed by an instance of the PREC resource. Consider the following Rez source code: ,
Courier
° d ONLN dµ » Ñ ”e +H- /* First the resource type definition: */ ° d ONLN d„ “ Ñ › Ÿ *
type 'PREC' { ° d ONLN dı ‹ Ñ Á œ *
string; ° d ONLN d Ê Ñ Ò ¢ *
}; ° d ONLN d ˙ Ñ[ *+ /* Now the real resource definition: */ ° d ONLN d8 Ñ *
° d ONLN dÉ. <:· (V ZVWe begin by defining the resource type as being a string. We then define an instance ° d ONLN dŸ.·:˛ (Vˇof the ° d ONLN d‡: <F (b Zresource with ° d ONLN dÓ: F˛ )COan ID of 103. Finally, we define the contents of the resource. The PostScript ° d ONLN d>F <R “ (n Z code above basically defines a ° d ONLN d]F “R˛ )ñ<dictionary named mydict within the userdict dictionary. The ° d ONLN döR <^ ü (z Zmydict dictionary is ° d ONLN dØR ü^˛ )cCdefined as having a maximum of 50 elements. Consult the PostScript ° d ONLN dÛ^ <j¯ (Ü Z[Language Reference Manual for more information concerning legal operations on dictionaries.
ZUprinting is disabled, so it is now considered obsolete, and use of it is unsupported. ° d ONLN dÈ <! ¶ *0Further Reference: @ X@ ° d ONLN d¸" N. R +
• ° d ONLN d˛" `.Å )8PostScript Language Reference Manual, Adobe Systems Inc. ° d ONLN d7. N: R (V l• ° d ONLN d9. `:ê ):Adobe Document Structuring Conventions, Adobe Systems Inc. ° d ONLN dt: NF R (b l• ° d ONLN dv: `FF ),LaserWriter Reference Manual, Addison-Wesley ° d ONLN d£R <^Ä (z ZCPostScript is a registered trademark of Adobe Systems Incorporated. ¡ X¡
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å ˜ ( õ ZPR 15 - Feeder Fodder
° d ONLN d Ä < è s *Printing
° d ONLN d õ < ß q * Written by: ° d ONLN d , õ Ñ ß Ã )H Zz Zimmerman ° d ONLN d 9 õÀ ߲ ( √È
April 1991 ° d ONLN d D ≥ < ø ( € Z-This Technical Note discusses the new Feeder ° d ONLN d q ≥ ø˛ )›0button available in the 6.1, and 7.0 versions of ° d ONLN d ¢ ø < À§ ( Á ZHthe LaserWriter driver. This Feeder button mechanism allows developers ° d ONLN d Í ø§ À˛ ( Á¬to insert code into ° d ONLN d ˛ À < ◊Á ( Û ZSthe LaserWriter driver to support a sheet feeder connected to a LaserWriter. This ° d ONLN dQ ÀÁ ◊˛ ( ÛNote ° d ONLN dV ◊ < „‘ ( ˇ ZWprovides a description of the button, as well as information required to implement one. X
° d ONLN dÆ < è *4 Introduction
° d ONLN dª# </Ê *UThe LaserWriter driver now implements a standard method for handling sheet feeders. ° d ONLN d#Ê/˛ (KMost ° d ONLN d/ <;– (W ZPLaserWriter sheet feeders need a way to present a user with a dialog as well as ° d ONLN de/–;˛ (WÓa way to ° d ONLN dn< <H ∫ (d Zdownload the PostScript
° d ONLN dÖ: ∫E ¡ (a ÿ®
° d ONLN dÜ< ¡H∞ ++ code necessary to control the feeder. In ° d ONLN d±<∞H˛ )Ôthe past, most ° d ONLN d¿H <T ≠ (p Zmanufacturers resorted ° d ONLN d◊H ≠T˛ )qCto modifying the LaserWriter driver’s code resources; however, this ° d ONLN dT <` Û (| Z&functionality is now possible without ° d ONLN dAT Û`˛ )∑5the need to patch existing resources in the driver—by ° d ONLN dw` <l ¡ (à Zadding three new resources. ° d ONLN dìx <Ñ ] *When ° d ONLN dòx ]Ñ˛ )!Uthe LaserWriter driver notices these three special resources in its resource fork, it ° d ONLN dÓÑ <ê™ (¨ ZMdisplays a Feeder button in the lower right corner of the Print dialog box. ° d ONLN d;Ñ™ê˛ (¨»It is important to ° d ONLN dNê <ú ˘ (∏ Z+note that this feature is not provided for ° d ONLN dyê ˘ú˛ )Ω7general application use, but rather only for developers ° d ONLN d±ú <® I (ƒ Zof ° d ONLN d¥ú I®˛ )
Ysheet feeders and other LaserWriter add-on devices. The button is always labeled Feeder, ° d ONLN d® <¥Ì (– ZYand there can be only one set of Feeder resources in the LaserWriter driver. Because of ° d ONLN dg®Ì¥˛ (– this ° d ONLN dl¥ <¿ Ì (‹ Z'restriction, you should not attempt to ° d ONLN dì¥ Ì¿˛ )±9use this feature to implement anything other than a sheet ° d ONLN dÕ¿ <à ] (Ë Zfeeder. ° d ONLN d’ÿ <‰ *\The first special resource contains code to implement the user interface of the feeder, and ° d ONLN d1ÿ‰˛ ( the ° d ONLN d5‰ < W ( Zother ° d ONLN d;‰ W˛ )Xtwo contain the PostScript code required to drive the feeder. When an application calls ° d ONLN dî <¸¬ ( ZSthe LaserWriter driver to display the Print dialog box, the driver looks for three ° d ONLN dÁ¬¸˛ (‡ resources of ° d ONLN dÙ˝ < S (% Ztype ,
Courier ° d ONLN d˘¸ S } )'feed' ° d ONLN dˇ˝ } à )*: and displays the Feeder button in the lower right corner ° d ONLN d9˝à ˛ (%¶of the dialog box if they ° d ONLN dS
< ç (2 Zare found. If no ° d ONLN de ç ∑ )Q'feed' ° d ONLN dk
∑⁄ )*@ resources are available, it does not display the Feeder button. ° d ONLN d¨" <. (J Z/When a user selects Print, the driver displays ° d ONLN d€" .˛ )‡-the standard Print dialog box with the Feeder ° d ONLN d . <: a (V Zbutton. ° d ONLN d. a:˛ )%X If a user clicks on the Feeder button, the driver displays a dialog box in front of the ° d ONLN dj: <Fj (b ZAPrint dialog box, which allows the user to configure the feeder, ° d ONLN d´:jF˛ (bà then returns to the Print dialog ° d ONLN dÃF <R" (n Z1box once the user confirms or cancels the feeder ° d ONLN d˝F"R˛ )Ê-configuration. This feeder dialog box should ° d ONLN d +R <^ N (z Znot ° d ONLN d .R N^ )+ contain an option to print, as this could ° d ONLN d YR ^˛ )æ2override choices made in the standard Print dialog ° d ONLN d å^ <j R (Ü Zbox. ¿ X¿
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øÏ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d , *Implementation
° d ONLN d 9 E Â *)To handle interaction with the user, you ° d ONLN d 8 9 Â Eá )Õ must install a resource of type ,
Courier ° d ONLN d X 8á D± )¢'feed' ° d ONLN d ^ 9± Eª )* ( ° d ONLN d ` 8ª D⁄ )
ID = ° d ONLN d e E Q ; ( n 6-8192 ° d ONLN d j F ; R Î )#') into the LaserWriter driver with the ° d ONLN d ë F Î R⁄ )∞1code required to manage the dialog box. Like all ° d ONLN d √ R ^j ( z 6BPrinting Manager code resources, this resource begins with a jump ° d ONLN d Rj ^⁄ ( zàtable, followed by the ° d ONLN d ^ j S ( Ü 6
actual code. ° d ONLN d) ^ S j⁄ );P The code is implemented as a procedure that is passed a single parameter. This ° d ONLN dz j vû ( í 6Vparameter is a rectangle defining the page size selected by the user. This page size ° d ONLN d– jû v⁄ ( íº
is equivalent ° d ONLN dfi w É 5 ( ü 6to the ° d ONLN d v 5 Ç _ ) rPaper ° d ONLN dÎ w _ ɧ )*I rectangle in the print record, meaning it defines the actual page size, ° d ONLN d4 w§ É⁄ ( ü¬ not just the ° d ONLN dA É èø ( ´ 6\printable area. The rectangle is expressed in 72 dpi coordinates and has a negative origin.
° d ONLN dû ß ∂ ú *'Go Ahead and Jump
° d ONLN d∞ √ œ Œ *#The jump table consists of a 68000 ° d ONLN d” ¬ Œ Œ „ )∂JMP ° d ONLN d÷ √ „ œú )& instruction that jumps to the proper ° d ONLN d¸ √ú œ⁄ )π
offset in the ° d ONLN d
œ € k ( ˜ 6resource. In this ° d ONLN d œ k €⁄ )SMcase, there is only one routine, so the code starts immediately following the ° d ONLN dk € Á g ( 6jump table. To ° d ONLN d{ € g Á⁄ )OJmake this step automatic, the jump table is created using a small assembly ° d ONLN dΔ Á Û g ( 6language header:
° d ONLN dŸ ˇ `
~ +HIMPORT ° d ONLN d‡ ˇ Ñ
¢ )$Feeder ° d ONLN dË ˇ Ã
g )H ; Feeder is NOT defined here... ° d ONLN d < U (0 ZStart ° d ONLN d ` t )$MAIN ° d ONLN d Ñ∞ )$<EXPORT ; This is the main entry point for the linker. ° d ONLN dS ` o (: ~JMP ° d ONLN dW Ñ ó )$7Feeder ; The one jump table entry in this table. ° d ONLN dë `( o (D ~END
° d ONLN dï4 @ ≤ (\ 6 This example first imports the ° d ONLN d¥3 ≤? ‹ )öFeeder ° d ONLN d∫4 ‹@` )* procedure, which can be ° d ONLN d”4`@⁄ )Ñdefined externally in the ° d ONLN dÌA M ∏ (i 6"language of your choice. Next is ° d ONLN d@ ∏L € )†Start ° d ONLN dA €M ‚ )#, ° d ONLN dA ‚M⁄ )3the main entry point to the jump table. By passing ° d ONLN dJM Y ÿ (u 6)this label to the link command, the jump ° d ONLN dsM ÿY⁄ )¿7table is located at the beginning of the resource. The ° d ONLN d´Z f N (Ç 6
next line is ° d ONLN d∏Z Nf ¸ )6%the actual jump table entry, and the ° d ONLN d›Y ¸e )ÆEND ° d ONLN d‡Zf⁄ )) is required to end the assembly-language ° d ONLN d
f rL (é 6?header. That’s all there is to it. The only thing one should ° d ONLN dIfLr⁄ (éjhave to change in this code ° d ONLN der ~ (ö 64fragment would be the name of the routine to import.
° d ONLN döñ • î *'The Real MacCode
° d ONLN d´± Ω ù *Now that the jump table is ° d ONLN dΔ± ùΩ⁄ )Ö:complete, it needs some place to jump. Although MPW C and ° d ONLN dΩ …5 ( 68Pascal examples are provided in this Note, the code can ° d ONLN d9Ω5…⁄ (ÂS be written in any language. As ° d ONLN dY… ’° (Ò 6Rmentioned before, the code is implemented as a procedure that takes one parameter. ° d ONLN d¨· Ì ^ * C Definition ° d ONLN dπ˘ y *In C, this looks like:
° d ONLN d– Ü * #include <Types.h> ° d ONLN dÁ & ö *
#include <Quickdraw.h> ° d ONLN d% 0 ê *
void FEEDER(Rect *r) ° d ONLN d/ : 1 *
{ ° d ONLN d!9 D ˛ *
. <Code to present and handle dialog...> ° d ONLN dPC N 1 *
}
° d ONLN dVZ f œ *(Since the assembler converts all labels ° d ONLN d~Z œfï )∑(to uppercase, the name of the procedure ° d ONLN d¶Yïeø )ΔFEEDER ° d ONLN d¨Zøf⁄ )* must ° d ONLN d≤f r (é 6:be capitalized to match the case of the label in the jump ° d ONLN dÏf r⁄ (é:%table. If you are using MPW, you can ° d ONLN d s w (õ 6use the assembler's ° d ONLN d &r w~ ì )_CASE ° d ONLN d *s ìô ) : directive to prevent the assembler from capitalizing the ° d ONLN d dsô⁄ (õ∑labels. Since ° d ONLN d s ã à (ß 6the rectangle is passed ° d ONLN d ã àã⁄ )pGusing the C calling convention (i.e., the caller strips the parameter), ¿ 4¿˘
(÷ 62 ) of 6 (÷üPR 15 - Feeder Fodder +
M.PR.FeederFodder ˇê ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -
April 1991 / X /
° d ONLN d < * ( F Z*there is no need to declare the procedure ° d ONLN d * *, )»as type ,
° d ONLN dZ < ä ™ * UNIT FeederSample; ° d ONLN dq â < î ë *
INTERFACE ° d ONLN dÑ ì < û Ê *
" USES Types, Quickdraw; ° d ONLN dß ß < ≤ ı *% PROCEDURE Feeder(r: Rect); C; ° d ONLN dÕ ª < Δ ™ * IMPLEMENTATION ° d ONLN d‰ œ < ⁄ Ê *" PROCEDURE Feeder(r: Rect); ° d ONLN d Ÿ < ‰ } *
BEGIN ° d ONLN d „ < Ó6 *
2 <Code to present and handle dialog...> ° d ONLN dP Ì < ¯ x *
END; ° d ONLN d] ˜ < d *
END.
° d ONLN df
< ÷ *"So this is straight forward. The ° d ONLN dà
÷˛ )ö<procedure Feeder is defined as having one parameter (r), and ° d ONLN d≈ <%U (A Z?the C directive is used so that the stack is handled correctly. ° d ONLN d1 <=∞ *MIf you are using some other development environment that doesn't support the ° d ONLN dS1∞=˛ (YŒC directive, you ° d ONLN dd= <Iq (e ZDhave to do a little more work, making the definition look like this:
" USES Types, Quickdraw; ° d ONLN dˆ} <à π * PROCEDURE Feeder; ° d ONLN dë <ú ™ * IMPLEMENTATION ° d ONLN d'• <∞ *( FUNCTION StealRectalParam: Rect; ° d ONLN dPØ <∫ö *
F INLINE $2EAE, 0008; { MOVE.L 8(A6),(A7) } ° d ONLN dó√ <Œ π * PROCEDURE Feeder; ° d ONLN d±Õ <ÿ s *
VAR ° d ONLN dΩ◊ <‚ Ø *
r: Rect; ° d ONLN d’· <Ï } *
BEGIN ° d ONLN d„Î <ˆ Ê *
" r := StealRectalParam; ° d ONLN dˇ <
6 *2 <Code to present and handle dialog...> ° d ONLN dB < x *
END; ° d ONLN dO < d *
END.
° d ONLN dX) <5 Ä *First of all, a ° d ONLN dh) Ä5˛ )DOunit is defined, and the proper interfaces are included. The definition of the ° d ONLN d∏5 <A f (^ ZFeeder ° d ONLN dæ6 fB ≠ )* procedure in ° d ONLN dÃ6 ≠B ¡ )Gthe ° d ONLN d–5 ¡A ) INTERFACE ° d ONLN dŸ6 B˛ )?3 section is required to make the label available to
° d ONLN d
C <O Ê (k Zexternal modules. In the ° d ONLN d'B ÊNH )™IMPLEMENTATION ° d ONLN d5CHOá )b
section, ° d ONLN d?CáO˛ )?one starts with the ° d ONLN dSO <[ ¨ (x ZStealRectalParam ° d ONLN dcP ¨\ƒ )p8 function, which is used to get the rectangle passed by ° d ONLN dõPƒ\˛ (x‚ the Printing ° d ONLN d®\ <h ˘ (Ñ Z%Manager without actually removing it ° d ONLN dÕ\ ˘h˛ )Ω3from the stack. If you declared the rectangle as a ° d ONLN di <u ç (ë Zparameter to the ° d ONLN dh çt ∑ )QFeeder ° d ONLN di ∑u Ú )* procedure, ° d ONLN d$h Út );Feeder ° d ONLN d*i uœ )*# would remove the parameter before ° d ONLN dMiœu˛ )≥
° d ONLN d * 6 √ *%"To solve this problem, define the ,
Courier ° d ONLN d " ) √ 5 Ì )´Feeder ° d ONLN d ( * Ì 6ç )* procedure with no parameters. ° d ONLN d G *ç 6⁄ )† This way, the ° d ONLN d V 6 B B ( _ 6Feeder ° d ONLN d \ 7 B C fi )* procedure leaves the parameter ° d ONLN d | 7 fi C⁄ )ú5right where the caller left it. To get the parameter ° d ONLN d ≤ D P Ê ( l 6,without removing it from the stack, use the ° d ONLN d fi C Ê OV )ŒStealRectalParam ° d ONLN d Ó DV PY )p ° d ONLN d Ô DY P⁄ )function, which moves the ° d ONLN d Q ] fl ( y 6+parameter from its normal location (off of ° d ONLN d4 P fl \ Ì )«A6 ° d ONLN d6 Q Ì ] ) ) into the ° d ONLN dA Q ]⁄ )-)location pointed to by the stack pointer. ° d ONLN dl ^ j 6 ( Ü 6Since ° d ONLN dr ] 6 i ¶ ) StealRectalParam ° d ONLN dÇ ^ ¶ j´ )p9 is a function, the stack pointer is already pointing to ° d ONLN dª ^´ j⁄ ( Ü…
the return ° d ONLN dΔ k w i ( ì 6
value. When ° d ONLN d” j i v Ÿ )QStealRectalParam ° d ONLN d„ k Ÿ w$ )p returns, the ° d ONLN dÒ j$ vN )KFeeder ° d ONLN d˜ kN w∞ )* routine gets the ° d ONLN d k∞ w⁄ )b rectangle ° d ONLN d w É ( ü 64parameter, without having removed it from the stack. ° d ONLN dH è õ ` * Tickled Link ° d ONLN dU ß ≥ *2Now you have the jump table and the code, but you ° d ONLN dá ß ≥⁄ )˜,still need to link them together. This step ° d ONLN d¥ ≥ ø g ( € 6is pretty simple, ° d ONLN dΔ ≥ g ø⁄ )OObut remember to specify the starting location of the jump table. It looks like ° d ONLN d ø À Z ( Á 6the following:
° d ONLN d% ◊ ‚W *@ Link -w -t feed -c ZzZz -rt feed=-8192 -m START -sg Feeder ∂ ° d ONLN df · ÏC *
< Feeder.a.o ∂ # This file MUST be first. ° d ONLN d£ Î ˆ { *
Feeder.p.o ∂ ° d ONLN d∏ ı ∑ *
"{Libraries}"Runtime.o ∂ ° d ONLN dŸ ˇ
¡ *
" "{Libraries}"Interface.o ∂ ° d ONLN d¸ º *
! "{PLibraries}"SANELib.o ∂ ° d ONLN d ∑ *
"{PLibraries}"PasLib.o ∂ ° d ONLN d? ( m *
-o Feeder
° d ONLN dQ4 @ Ÿ *.First tell the linker to link the code into a ° d ONLN d3 Ÿ? )¡'feed' ° d ONLN dÖ4@ô )* resource with an ID of -8192. ° d ONLN d•4ô@⁄ )ñ
Next, specify ° d ONLN d≥A M (i 60that the resource begins with the code at label ° d ONLN d„@ L )ÿSTART ° d ONLN dËAM™ )#!. This label was defined by the ° d ONLN d A™M÷ )óassembly ° d ONLN dA÷M⁄ ),- ° d ONLN dM Y E (u 6 language ° d ONLN dM EY⁄ )-Yused to generate the jump table. Finally, tell the linker to link all of the code into a ° d ONLN duZ f â (Ç 6single segment named ° d ONLN däY âe ≥ )qFeeder ° d ONLN dêZ ≥f º )*. ° d ONLN díZ ºf⁄ ) : Obviously, the list of libraries and object files changes ° d ONLN dÕf r • (é 6 depending upon the language ° d ONLN dÈf •r⁄ )ç>used, but the directives to the Link command should remain the ° d ONLN d(r ~ 4 (ö 6same. ° d ONLN d.ä ñ K *Well Fed ° d ONLN d7£ Ø q *So that should be ° d ONLN dI£ qØ )Y!enough to get some code into the ° d ONLN dj¢ ÆG )¨'feed' ° d ONLN dp£GØ⁄ )* resource. Now you need to ° d ONLN dåØ ªR (◊ 6Cactually control the feeder during the print job. To do this, you ° d ONLN dœØRª⁄ (◊pmust use PostScript. Your ° d ONLN dͺ » ü (‰ 6 driver should also provide a ° d ONLN dª ü« … )á'feed' ° d ONLN d
· TÌ ~ )'PREC' ° d ONLN d‚ ~Óá )*3 103 code. Additional PostScript to be downloaded ° d ONLN dC‚áÓ⁄ (
•can be stored in ° d ONLN dTÓ ˙ B ( 6'feed' ° d ONLN dZÔ B˚ Í )*$ -8190. The PostScript code in the ° d ONLN d~Ó Í˙ )®'feed' ° d ONLN dÑÔ˚e )* resource should ° d ONLN dïÔe˚⁄ )Qredefine (i.e., patch) the ° d ONLN d∞˚ É (# 6PostScript operators ° d ONLN d≈˚ É⁄ )k@required to handle switching feeders. A likely candidate is the ° d ONLN d P (0 6showpage ° d ONLN d P )8. operator called at the end of each page. As ° d ONLN d < ⁄ )–'always, calling or redefining operators ° d ONLN d d 3 (< 6<defined by the LaserPrep (md) dictionary is not supported. ° d ONLN d †3 ⁄ (<Q#If your device is connected via the ° d ONLN d ƒ ,Ø (H 6NLaserWriter’s serial port, you can license code from Adobe Systems, Inc. that ° d ONLN d
Ø,⁄ (HÕmakes it ° d ONLN d
, 8p (T 6Kpossible to access the serial port while the LaserWriter is connected over ° d ONLN d
f,p8⁄ (TéAppleTalk. For more ° d ONLN d
{8 D ß (` 6 information, contact Adobe at: ° d ONLN d
ùP Ñ\ Ë +lAdobe Systems, Inc. ° d ONLN d
¥\ Ñh Ó * 1585 Charleston Road ° d ONLN d
Ãh Ñt * Mountain View, CA 94043 ° d ONLN d
Ët ÑÄ œ * (415) 961-4400 ¿ 4¿˘
(÷ 64 ) of 6 (÷üPR 15 - Feeder Fodder +
M.PR.FeederFodder ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -
April 1991 / X /
° d ONLN d < ) _ ( E ZOnce a ° d ONLN d _ )˛ )#Uuser has confirmed the configuration from the dialog box, you can edit the PostScript ° d ONLN d ] ) < 5 ˘ ( Q Z*code in the -8191 resource to reflect the ° d ONLN d á ) ˘ 5˛ )Ω3choices made. However, when MultiFinder is active, ° d ONLN d ª 5 < As ( ] ZByou cannot add or change the size of resources in the LaserWriter ° d ONLN d ˝ 5s A˛ ( ]ë driver. For this reason, you ° d ONLN d B < N Ñ ( j Zshould pad the ,
Courier ° d ONLN d* A Ñ M µ )H'feed' ° d ONLN d1 B µ N˛ )1@-8191 resource to the maximum size. This padding can be done by ° d ONLN dr N < ZÄ ( v ZEadding spaces at the end. If you later need to resize the resource, ° d ONLN d∑ NÄ Z˛ ( vûyou can simply overwrite ° d ONLN d– Z < f ø ( Ç Zsome of the spaces. For ° d ONLN dÈ Z ø f˛ )É>more information on printer drivers under MultiFinder, see the ° d ONLN d( f < r ì ( é ZLearning to Drive ° d ONLN d9 f ì r )W document, which is part ° d ONLN dR f r˛ )Ç.of “Developer Essentials,” and is available on ° d ONLN dÅ r < ~` ( ö Z;AppleLink, the Apple FTP site, and the Developer CD Series. ° d ONLN dΩ ã < ó4 *3You probably need to provide other resources along ° d ONLN d ã4 ó_ )¯ with the ° d ONLN d˘ ä_ ñâ )+'feed' ° d ONLN dˇ ãâ ó˛ )* resources; for example, ° d ONLN d ò < § j ( ¿ Z you need ° d ONLN d! ó j £ î ).'DITL' ° d ONLN d' ò î § ´ )* and ° d ONLN d, ó ´ £ ’ )'DLOG' ° d ONLN d2 ò ’ §π )*2 resources for the dialog box. This is okay, but ° d ONLN dd òπ §˛ )‰
you should be ° d ONLN dr § < ∞ Ï ( à Z&sure to pick unique resource types to ° d ONLN dò § Ï ∞˛ )∞9avoid confusing the LaserWriter driver. In the case of a ° d ONLN d“ ∞ < ºù ( ÿ ZJFeeder button, you are a guest in someone else’s house. It would be wise ° d ONLN d ∞ù º˛ ( ÿªto avoid rearranging ° d ONLN d1 º < » z ( ‰ Zthe furniture. ° d ONLN d@ ’ < · */When the LaserWriter driver actually opens the ° d ONLN do ’ ·‘ )·(connection to the printer, it looks for ° d ONLN dó ‘‘ ‡˛ )∑'feed' ° d ONLN dû · < Ì÷ ( ZTresources -8191 and -8190. If they exist, they are downloaded. For those familiar ° d ONLN dÚ ·÷ Ì˛ ( Ùwith the ° d ONLN d˚ Ì < ˘ è ( Z 'PREC' 103 ° d ONLN d Ó è ˙_ )S&method of downloading PostScript code ° d ONLN d, Ó_ ˙˛ )– (refer to Technical Note #192, ° d ONLN dK ˚ < € (# Z!Surprised in LaserWriter 5.2 and ° d ONLN dl ˚ € )ü Newer), the ° d ONLN dx ˙C )>'feed' ° d ONLN d~ ˚C» )* resources are downloaded ° d ONLN dò ˚»Ï )Öbefore ° d ONLN dû ˚Ï˛ )$ the ° d ONLN d£ < â (0 Z 'PREC' 103 ° d ONLN dÆ â• )M=resource. In the case of background printing, the resources ° d ONLN dΕ˛ (0√are copied into the ° d ONLN dˇ <! ì (= Zspool file. Since ° d ONLN d ì Ω )W'feed' ° d ONLN d Ω! Ú )* resources ° d ONLN d# Ú!˛ )53-8191 and -8190 are automatically downloaded by the ° d ONLN dW! <-: (I Z5LaserWriter, they must contain PostScript code. The ° d ONLN då!:-˛ )˛)format of these PostScript resources is a ° d ONLN d∂- <9 ø (U Zstring of ASCII characters ° d ONLN d—- ø9˛ )ÉAwithout any length byte or terminator. The size of the string is ° d ONLN d9 <E (a Z2determined by the size of the resource; there are ° d ONLN dE9 E˛ )„0no special size restrictions on these resources, ° d ONLN dvE <Q (m Z0and their only requirement is that they contain ° d ONLN d¶E Q˛ )‚+PostScript code. To make debugging easier, ° d ONLN d“Q <]‡ (y ZZyou should separate lines of PostScript using a carriage return character (13 or $0D hex).
° d ONLN d-u <Ñ *' Don't Feed The Print Monster
° d ONLN dJê <ú g * One last ° d ONLN dSê gú˛ )+Qimportant note concerns the 6.1 version of the LaserWriter driver, shipped on the ° d ONLN d•ú <®" (ƒ Z0Macintosh Printing Tools disk included with the ° d ONLN d’ú"®˛ )Ê,Personal LaserWriter LS and StyleWriter. In ° d ONLN d ® <¥k (– Z=this version of the driver, the Feeder button will only work ° d ONLN d ?®k¥˛ (–âwhen Background printing is ° d ONLN d [¥ <¿? (‹ Z6disabled. There is a problem with the driver finding ° d ONLN d ë¥?¿˛ (‹]$the 'feed' resources when Background ° d ONLN d ∂¿ <Ãø (Ë ZMprinting is enabled. This problem has been solved in the 7.0 version of the ° d ONLN d
¿øÃ˛ (Ë› driver which ° d ONLN d
à <ÿi (Ù Z:should be used instead of the 6.1 driver as soon as it is ° d ONLN d
JÃiÿ˛ (Ùá available. Since there is no ° d ONLN d
hÿ <‰ò ( ZHworkaround for the problem, you don't really have to do anything except ° d ONLN d
∞ÿò‰˛ ( ∂for possibly noting it ° d ONLN d
«‰ <‚ ( ZVin your documentation. Any note should recommend upgrading to the 7.0 version of the ° d ONLN d ‰‚˛ ( driver ° d ONLN d $ <¸ õ ( Zas soon as possible.
° d ONLN d 9 <# æ *'Driving Miss Lasey
° d ONLN d L0 << Ã * Now that you have the two or ° d ONLN d i0 Ã< Á )êthree ° d ONLN d o/ Á; )'feed' ° d ONLN d u0<˛ )*2 resources, the big question is installation. How ° d ONLN d ®< <Ho (d ZAshould you ship these things? There are two methods. The first ° d ONLN d È<oH˛ (dç method involves licensing the ° d ONLN d H <T. (p Z1LaserWriter driver from Apple Software Licensing ° d ONLN d 8H.T˛ )Ú'(SW.License on AppleLink). This method ° d ONLN d `T <`Á (| Z]is only required for “turn-key” systems, where all installation is done for the user and you ° d ONLN d ΩTÁ`˛ (|must ° d ONLN d ¬` <l¬ (à ZRship the LaserWriter driver as part of your product. The second method, which is ° d ONLN d
`¬l˛ (à‡ by and large ° d ONLN d
!l <x È (î Z'preferred as it requires no licensing, ° d ONLN d
Hl Èx˛ )≠<is to ship your resources in an installer application. This ° d ONLN d
Öx <Ñ≤ († ZOapplication simply opens the LaserWriter file and adds the necessary resources. ¿ X¿
° d ONLN d D På *OSo this should be all the information you need to implement the feed resources ° d ONLN d Z Då P⁄ ( l™for your device. ° d ONLN d l P \Ç ( x 6MIf you intend to drive a sheet feeder through the LaserWriter’s serial port, ° d ONLN d π PÇ \⁄ ( x†be sure to contact ° d ONLN d à \ hk ( Ñ 6FAdobe Systems, Inc. for the most current implementation and licensing ° d ONLN d \k h⁄ ( Ñâinformation. Although ° d ONLN d) h tÅ ( ê 6Jthe Feeder button could theoretically be used for other purposes, it will ° d ONLN ds hÅ t⁄ ( êüalways be labeled ° d ONLN dÖ t Ä G ( ú 6 “Feeder” ° d ONLN dé t G Ä⁄ )/Nby the LaserWriter driver. Because of this consistency, developers should not ° d ONLN d› Ä åV ( ® 6Eattempt to extend its functionality beyond support for sheet feeders. ° d ONLN d# ∞ º Ç *0Further Reference: € 4 €˘ ° d ONLN d6 Ω * … . +
• ° d ONLN d8 Ω < …] )8PostScript Language Reference Manual, Adobe Systems Inc. ° d ONLN dq … * ’ . ( Ò H• ° d ONLN ds … < ’ )&Technical Note M.IM.LWDriverSuprises — ° d ONLN dú ’ ` ·! +$ ' Surprises in LaserWriter 5.2 and Newer ° d ONLN dƒ Ì ˘\ ( 6CPostScript is a registered trademark of Adobe Systems Incorporated. ¿ 4¿˘
(÷ 66 ) of 6 (÷üPR 15 - Feeder Fodder +
M.PR.FeederFodder ˇf ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç6 ( ú ZPR 16 - Fun With PrJobMerge
° d ONLN d Å < ê s *Printing
° d ONLN d & ú < ® t * Revised by: ° d ONLN d 2 ú Ñ ® – )HMatt Deatherage ° d ONLN d B úŒ ®˛ ( ƒÏMay 1992 ° d ONLN d K ® < ¥ q ( – Z Written by: ° d ONLN d W ® Ñ ¥T )H(Scott “Zz” Zimmerman and Matt Deatherage ° d ONLN d Ä ®≈ ¥˛ ( –„
March 1992 ° d ONLN d ã ¿ < à ˛ ( Ë Z#This Technical Note discusses some ° d ONLN d Æ ¿ ˛ Ã˛ )¬1interesting behavior you’ll encounter while using ° d ONLN d ‡ à < ÿÄ ( Ù ZCPrJobMerge with the 7.0 and 7.1 versions of the LaserWriter driver. ° d ONLN d$ ÿ < ‰ ë * Changes since ° d ONLN d2 ÿ ë ‰ Ÿ )U March 1992: ° d ONLN d= ÿ Ÿ ‰˛ )H< Corrected the Vulcan-like “THPring” typo to correctly read ° d ONLN dz ‰ < ∑ ( ZM“THPrint,” and changed a comment in the code to mean what I originally meant. X ° d ONLN d»
< Ï *&"Like many Printing Manager calls, ,
Courier ° d ONLN dÍ Ï2 )∞
PrJobMerge ° d ONLN dÙ
27 )F ° d ONLN dı
7˛ )&is implemented by the currently chosen ° d ONLN d <" ‹ (> Z!printer driver. This makes sense ° d ONLN d= ‹"˙ )†:after consideration—since the printer driver may store job ° d ONLN dw˙"˛ (>- ° d ONLN dx" <.û (J ZKspecific information anywhere in the print record, only the printer driver ° d ONLN d√"û.˛ (Jºcan correctly merge ° d ONLN d◊. <: fi (V Z%this into a destination print record. ° d ONLN d˝G <S *+The LaserWriter driver’s implementation of ° d ONLN d(F RR )–
PrJobMerge ° d ONLN d2GRSÖ )F has a few ° d ONLN d=GÖS˛ )3bugs in versions 7.0 and ° d ONLN dVS <_ P ({ Z7.1.
° d ONLN d[w <Ü ñ *' Fun Thing #1
° d ONLN dhì <ü z *Historically, ° d ONLN dví zû ¿ )>
PrJobMerge ° d ONLN dÄì ¿üé )F, hasn’t worked correctly in the LaserWriter ° d ONLN d¨ìéü˛ )Œdriver. The driver does ° d ONLN dƒü <´À (« ZXnot correctly merge all job-related data (like the number of copies requested) into the ° d ONLN d üÀ´˛ («È destination ° d ONLN d(´ <∑ V (” Zprint ° d ONLN d.´ V∑˛ )Vrecord, so printing multiple copies of multiple documents from the Finder isn’t really ° d ONLN dÖ∑ <√ Í (fl Z%possible with the LaserWriter driver. ° d ONLN d´œ <€ k * The only ° d ONLN d¥œ k€˛ )/Ppossible workaround is to present a different job dialog for each document to be ° d ONLN d€ <Á x ( Z
printed, but ° d ONLN d€ xÁ˛ )<Mthis isn’t recommended—especially since the job dialog doesn’t tell you which ° d ONLN d`Á <Û “ ( Z document you’re about to print.
° d ONLN dÄ < ñ *' Fun Thing #2
° d ONLN dç& <20 *4As if this wasn’t enough excitement for one driver, ° d ONLN d¡&02˛ )Ù*in versions 7.0 and 7.1 of the LaserWriter ° d ONLN dÏ3 <? [ ([ Zdriver ° d ONLN dÛ2 [> ° )
PrJobMerge ° d ONLN d˝3 °?) )F actually manages to destroy ° d ONLN d3)?fl )à(all the job-specific information in the ° d ONLN dB3fl?˛ )∂source ° d ONLN dI? <Kw (g ZHprint record after it doesn’t copy it into the destination print record. ° d ONLN díW <c œ * There is a workaround for this ° d ONLN d±W œc˛ )ì;problem—make a copy of the source print record and pass the ° d ONLN dÌd <p j (å Zcopy to ° d ONLN dıc jo ∞ ).
PrJobMerge ° d ONLN dˇd ∞pB )F. If you pass the copy to ° d ONLN dcBoà )í
PrJobMerge ° d ONLN d#dàp¨ )F, you ° d ONLN d)d¨p˛ )$can just replace ° d ONLN d:p <| Ç (ô Z
PrJobMerge ° d ONLN dDq Ç}| )F1 with your own routine that makes a copy, merges ° d ONLN duq|}˛ )˙ it into the destination, and ° d ONLN dí} <â Ü (• Zdisposes of the ° d ONLN d¢} ÜⲠ)JOcopy. This will work for all printer drivers, although it’s necessary only with ° d ONLN dÚâ <ï Ó (± Z&version 7.0 of the LaserWriter driver. ¡ X¡
*%PR 16 - Fun With PrJobMerge (÷1 ) of 2 (Ï ZM.PR.FunWithPrJobMerge ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ≤ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5 ¯ *$0Such a procedure might look like this in Pascal: ,
Courier
° d ONLN d 1 A L& *6PROCEDURE NewPrJobMerge(hPrintSrc,hPrintDst: THPrint); ° d ONLN d h U ` ; * VAR ° d ONLN d p _ j ï *
copyError: OSErr; ° d ONLN d ä i t § *
hPrintTemp: THPrint; ° d ONLN d ß } à E * BEGIN ° d ONLN d ± á í® *
P hPrintTemp := hPrintSrc; {make our own copy of the print record handle} ° d ONLN d ë ú *
7 PrSetError(copyError); {so we can get it later} ° d ONLN do • ∞ € *
' IF copyError = noErr THEN BEGIN ° d ONLN dó Ø ∫l *
D {hPrintTemp is now a copy of the original source record} ° d ONLN d‹ 𠃮 *
P PrJobMerge(hPrintTemp,hPrintDst); {This messes up hPrintTemp, but we ° d ONLN d- √ Œ: *
: don't care} ° d ONLN dh Õ ÿ « *
# END; {if copyError = noErr} ° d ONLN då ◊ ‚≠ *
Q IF hPrintTemp <> NIL THEN DisposHandle(Handle(hPrintTemp)); {only a copy, ° d ONLN dfi · Ï£ *
O remember!} ° d ONLN d. Î ˆ @ *
END;
° d ONLN d7
1 *&'Don’t Go Overboard Trying to Solve This
° d ONLN d_) 5 Ç *Although the bugs in ° d ONLN dt( Ç4 » )j
PrJobMerge ° d ONLN d~) »5P )F in versions 7.0 and 7.1 of ° d ONLN dö)P5⁄ )àthe LaserWriter driver make ° d ONLN d∂5 A d (] 6certain kinds of ° d ONLN d«5 dA⁄ )LKprinting multiple documents impossible without device-specific workarounds, ° d ONLN dA M ü (i 6we strongly encourage you ° d ONLN d-A üM ± )ánot ° d ONLN d0A ±M/ ) to implement such code. ° d ONLN dIA/M⁄ )~$Any code that tries to replicate the ° d ONLN dnN Z U (v 6 function of ° d ONLN dzM UY õ )=
PrJobMerge ° d ONLN dÌó £v (ø 6Kfunction, your application is a prime candidate for compatibility problems. ° d ONLN d9« ” Ç *0Further Reference: Ú 4Ú˘ ° d ONLN dL‘ *‡ . +
• ° d ONLN dN‘ <‡ ç )Inside Macintosh ° d ONLN d^‘ ç‡2 )Q!, Volume II, The Printing Manager ¡ 4¡˘
(÷ 62 ) of 2 (÷{PR 16 - Fun With PrJobMerge +
M.PR.FunWithPrJobMerge ˇ ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åq ( õ Z#PR 17 - ImageWriter II Paper Motion
° d ONLN d $ Ä < è s *Printing
° d ONLN d . õ < ß t * Revised by: ° d ONLN d ; õ≈ ߲ ( √„
March 1988 ° d ONLN d F ß < ≥ q ( œ Z Written by: ° d ONLN d R ß Ñ ≥ – )HGinger Jernigan ° d ONLN d b ßÀ ≥˛ ( œÈ
April 1986 ° d ONLN d m ø < À ı ( Á Z)The purpose of this technical note is to ° d ONLN d ñ ø ı À˛ )π3answer the many questions asked about why the paper ° d ONLN d À < ◊ ( Û Z,moves the way it does on the ImageWriter II. X ° d ONLN d ˜ < ¸ *%%Many people have asked why the paper ° d ONLN d ¸˛ )ƒ2is rolled backward at the beginning of a Macintosh ° d ONLN dO ¸ < ($ Z2print job on the ImageWriter II. First, note that ° d ONLN dÅ ¸ ˛ )‡/this only happens with pin-feed paper (i.e. not ° d ONLN d± <Ü (0 ZGwith hand-feed or the sheet-feeder) and only at the beginning of a job. ° d ONLN d˘ <, â *It is not a bug, ° d ONLN d
â,˛ )MLand it is not malicious programming. It is simply that users are told in the ° d ONLN dW, <8 m (T Z
manual to ° d ONLN da, m8˛ )1Uload pin-feed paper with the top edge at the pinch-rollers, making it easy to rip off ° d ONLN d∑8 <D® (` ZOthe printed page(s) without wrecking the paper that is still in the printer or ° d ONLN d8®D˛ (`Δhaving to roll the ° d ONLN dD <Pˆ (l Z\paper up and down manually. At the end of every job, the software makes sure that the paper ° d ONLN duDˆP˛ (lis ° d ONLN dxP <\ô (x ZMleft in this position, leaving the print-head roughly an inch from the edge. ° d ONLN d≈Pô\˛ (x∑If something is to be ° d ONLN d€\ <h` (Ñ Z?printed higher than that, the paper has to be rolled backwards. ° d ONLN du <Å: *6As you are probably aware, the “printable rectangle” ( ,
rPage ° d ONLN d£¶ l≤ )#' is at that position for both printers. ° d ONLN dÀæ < e (Ê Z There is ° d ONLN d‘æ e ˛ ))Tno way to eliminate the reverse-feed action, because the user would have to load the ° d ONLN d) <÷π (Ú ZMpaper a different way AND the software would have to know that this was done. ° d ONLN dx‚ <Ó¨ *QIncidentally, in addition to the paper motion described above, there is also the ° d ONLN d…‚¨Ó˛ (
“burp.” This is a ° d ONLN d€Ó <˙ª ( ZV1/8-inch motion back and forth to take up the slop in the printer’s gear-train. It is ° d ONLN d1Óª˙˛ (Ÿ
needed on the ° d ONLN d?˙ <q (" ZAold-model printer, and there is debate about whether or not it’s ° d ONLN dÄ˙q˛ ("èneeded on ALL ImageWriter ° d ONLN dö <® (. ZLIIs, or only some, or none. The burp has been in and out of the ImageWriter ° d ONLN dÊ®˛ (.ΔII code in various ° d ONLN d˘ < ∑ (: Z releases; right now it’s in. ¡ X¡
*ú#PR 17 - ImageWriter II Paper Motion (÷1 ) of 1 (Ï ZM.PR.ImageWriterIIPaper ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øº ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç ≤ ( ú Z PR 18 - The ° d ONLN d o ≤ Dz )v&Effect of Spool-a-page/Print-a-page on ° d ONLN d 3 Å < î ∫ ( Æ ZShared Printers
° d ONLN d C ì < ¢ s *Printing
° d ONLN d M Æ < ∫ t * Revised by: ° d ONLN d Z Æ≈ ∫˛ ( ÷„
March 1988 ° d ONLN d e ∫ < Δ q ( ‚ Z Written by: ° d ONLN d q ∫ Ñ Δ Ã )HGinger Jenigan ° d ONLN d Ä ∫Œ Δ˛ ( ‚ÏMay 1987 ° d ONLN d â “ < fiÀ ( ˙ ZPThis technical note discusses drawbacks of using the spool-a-page/ print-a-page ° d ONLN d Ÿ “À fi˛ ( ˙È method of ° d ONLN d „ fi < Í e ( Z printing. X ° d ONLN d Ì <Ë *%RThe “spool-a-page/print-a-page” method of printing prints each page of a document ° d ONLN d?˲ (+as a ° d ONLN dD < œ (8 Z separate job instead of calling ,
Courier ° d ONLN dd œ )ì PrPicFile ° d ONLN dm i )? to print the entire ° d ONLN dÇi ˛ )[ picture file. Many applications ° d ONLN d¢ <(è (D ZCadopted this method of printing to avoid running out of disk space ° d ONLN d è(˛ (D≠while the ImageWriter ° d ONLN d˚( <4 Æ (P Zdriver was spooling the ° d ONLN d( Æ4˛ )rEdocument to disk. As long as you are printing to a directly connected ° d ONLN dY4 <@ (\ Z)ImageWriter, you’re fine, but if you are ° d ONLN dÇ4@˛ )‘.printing to remote or shared devices (like the ° d ONLN d±@ <L ¬ (h ZAppleTalk ImageWriter and ° d ONLN dÀ@ ¬L˛ )ÜAthe LaserWriter), this method may create significant problems for ° d ONLN d
L <X e (t Z the user. ° d ONLN dd <pà *UWhen a job is initiated by the application, the driver establishes a connection with ° d ONLN dldÃp˛ (åÍ the printer ° d ONLN dxp <| Ö (ò Zvia AppleTalk. ° d ONLN dáp Ö|˛ )IMWhen the job is completed, the driver closes the connection, allowing another ° d ONLN d’| <àr (§ ZDjob the opportunity to print. If each page is a job in itself, then ° d ONLN d|rà˛ (§ê the connection is closed and ° d ONLN d6à <î! (∞ Z-reopened between each page, allowing another ° d ONLN dcà!î˛ )Â-application to print between the pages of the ° d ONLN dëî <†Õ (º ZSdocument, which, as you might imagine, could present a significant problem. If two ° d ONLN d‰îÕ†˛ (ºÎ
• ° d ONLN dºm `y ≤ )Printing Manager ° d ONLN dÕy NÖ R (° l• ° d ONLN dœy `Ö" )$Technical Note M.IM.LaserWriterOpt — ° d ONLN d˜Ö ÑëW +$ )Optimizing for the LaserWriter—Techniques ¡ X¡
(÷ ZBPR 18 - The Effect of Spool-a-page/Print-a-page on Shared Printers (÷1 ) of 1 (Ï Z M.PR.Spooler ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øH ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å] ( õ Z!PR 19 - Using Laser Prep Routines
° d ONLN d " Ä < è s *Printing
° d ONLN d , õ < ß t * Revised by: ° d ONLN d 9 õ≈ ߲ ( √„
March 1988 ° d ONLN d D ß < ≥ q ( œ Z Written by: ° d ONLN d P ß Ñ ≥ – )HGinger Jernigan ° d ONLN d ` ßœ ≥˛ ( œÌ July 1987 ° d ONLN d k ø < ÀÖ ( Á ZFThis technical note addresses the issues involved in depending on the ° d ONLN d ± øÖ À˛ ( Á£procedures and constants ° d ONLN d À < ◊ Ë ( Û Z%defined in the Laser Prep dictionary. X ° d ONLN d < ¸s *%BWhen you are writing an application that uses PostScript heavily, ° d ONLN d2 s ¸˛ (ë it is very tempting to call the ° d ONLN dR ¸ < ($ Z procedures already defined in ° d ONLN dp ¸ ˛ )éAthe Laser Prep dictionary, rather than taking up the space in the ° d ONLN d≤ <i (0 Z=printer’s memory with PostScript procedures of your own. Or, ° d ONLN dÔi˛ (0á if a procedure in the dictionary ° d ONLN d < † (< Zdoesn’t do what you ° d ONLN d$ † ˛ )dJneed it to do, it is tempting to go in and change it to do what you really ° d ONLN do <, W (H Zwant. ° d ONLN du8 <D *(Unfortunately, we cannot guarantee that ° d ONLN dù8 D˛ )œ/either the name or the function of a particular ° d ONLN dÕD <PL (l Z4procedure in the dictionary will stay the same when ° d ONLN dDLP˛ (lj"the LaserWriter driver changes. In ° d ONLN d$P <\$ (x Z.addition, some procedures may become obsolete ° d ONLN dRP$\˛ )Ë*and go away when the driver changes. Since ° d ONLN d}\ <h ≈ (Ñ Z the Laser Prep dictionary is ° d ONLN dö\ ≈h˛ )â?considered part of the source for the LaserWriter driver, Apple ° d ONLN d⁄h <tà (ê ZGreserves the right to make any changes to it that are deemed necessary. ° d ONLN d"Ä <åÀ *MBecause we cannot guarantee the permanence of the contents of the Laser Prep ° d ONLN doÄÀå˛ (®È dictionary, ° d ONLN d{å <òj (¥ Z=relying on its contents can pose a significant compatibility ° d ONLN d∏åjò˛ (¥àproblem. If you rely on the ° d ONLN d‘ò <§; (¿ Z6procedures defined in the Laser Prep dictionary, your ° d ONLN d
ò;§˛ )ˇ)application will have to be revised every ° d ONLN d4§ <∞ (à Z-time Apple releases a new LaserWriter driver. ° d ONLN dbº <»µ *PIf you feel that you absolutely must use or modify procedures in the Laser Prep ° d ONLN d≤ºµ»˛ (‰”dictionary, you ° d ONLN d¬» <‘ W ( Zmust ° d ONLN d«» W‘ ~ )always ° d ONLN dÕ» ~‘ )'" check the version that is loaded ° d ONLN dÔ» ‘˛ )†.into the printer before you print. This allows ° d ONLN d ‘ <‡π (¸ ZMyour application to take appropriate action if the version of the dictionary ° d ONLN dk‘π‡˛ (¸◊
that has been ° d ONLN dy‡ <ÏI ( Z8downloaded to the printer isn’t one that you know about.
° d ONLN d≤ <é *'.How To Check The Laser Prep Dictionary Version
° d ONLN d· <+ ˜ *'To determine the version of Laser Prep ° d ONLN d ˜+˛ )ª5that the printer may contain, you have to communicate ° d ONLN d>+ <7
(S Z*with the printer using the Printer Access ° d ONLN dh+
7˛ )Œ.Protocol (PAP); you can’t just send your query ° d ONLN dó7 <C_ (_ Z>through the LaserWriter driver because there is no way to get ° d ONLN d’7_C˛ (_} an answer back. The object code ° d ONLN dıC <O™ (k ZJand documentation for PAP are available from Apple’s Licensing department. ° d ONLN d@[ <g£ *JTo determine whether the dictionary has been downloaded and whether it is ° d ONLN dä[£g˛ (É¡the right one, send ° d ONLN dûg <s
(è Z-the following PostScript code to the printer: ¡ X¡
*G!PR 19 - Using Laser Prep Routines (÷1 ) of 3 (Ï ZM.PR.UsingLaserPrepRoutines ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øf ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d < ( † +$%!PS-Adobe-1.2 Query ° d ONLN d ' < 2| *
@%%Title: Query to establish Laser Prep ProcSet version propriety ° d ONLN d X 1 < < ı *
%%%?BeginProcSetQuery: AppleDict md xx ° d ONLN d ; < F n *
/md where{ ° d ONLN d ã E < P π *
/md get /av get cvi xx eq ° d ONLN d ¶ O < Z ë *
{(1)}{(2)}ifelse} ° d ONLN d π Y < d õ *
{(0)}ifelse = flush ° d ONLN d Œ c < n √ *
%%?EndProcSetQuery: unknown ° d ONLN d Î m < x U *
(& 67how to best handle this situation for your application. ° d ONLN d/ "§ *YIf the response is ‘1’, the printer is loaded with the correct version of the dictionary. ° d ONLN dâ. : 4 *If the ° d ONLN dê. 4:⁄ ) [response is ‘2’, then the dictionary exists but it isn’t the version you need. In this case ° d ONLN dÏ: F o (b 6you need to either ° d ONLN dˇ: oF⁄ )WKlet the user know, or proceed in as standard a fashion as possible, without ° d ONLN dKF RZ (n 6Ecalling or modifying routines contained in the Laser Prep dictionary.
6Bsignificant compatibility problem. Since we cannot guarantee that ° d ONLN djÂNÒ⁄ (
l the contents of the dictionary ° d ONLN dâÒ ˝á ( 6Pwill not change, these types of applications will have to be revised every time ° d ONLN dŸÒá˝⁄ (•we release a new ° d ONLN dÍ˝ à (% 6Rversion of the LaserWriter driver. Also, there is no way to know which version of ° d ONLN d<˝Ã ⁄ (%Íthe ° d ONLN d@ K (1 6DLaserWriter driver generated the PostScript file the application is ° d ONLN dÑ K⁄ (1i interpreting. You will have to ° d ONLN d£ ! ¿ (= 6%require that a particular version of ° d ONLN d» ¿!⁄ )®9the LaserWriter driver be used to generate the PostScript ° d ONLN d ! - “ (I 6+files that your application will interpret.
\Ñ ê ˆ (¨ 60this issue, please refer to Technical Note #122. ¡ 4¡˘
**2 ) of 3 (÷i!PR 19 - Using Laser Prep Routines +M.PR.UsingLaserPrepRoutines ˇÇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -Ï
March 1988 / X /
° d ONLN d A < M ¶ ( i ZFurther Reference: l X l ° d ONLN d N N Z R +
• ° d ONLN d N ` Z « )The Printing Manager ° d ONLN d * Z N f R ( Ç l• ° d ONLN d , Z ` f )$PostScript Language Reference Manual ° d ONLN d Q f N r R ( é l• ° d ONLN d S f ` r" )$Technical Note M.IM.DevIndPrinting — ° d ONLN d z r Ñ ~ +$ Device-Independent Printing ¡ X¡
(÷ Z!PR 19 - Using Laser Prep Routines (÷3 ) of 3 (Ï ZM.PR.UsingLaserPrepRoutines ˇ2 ◊# ˇ ˇˇˇˇ # ◊ ° d WORD S † å ° d WORD R… † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. WIQkWIQk +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
Ä ( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
l +& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
BÄ ( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É ° d WORD † ç
IR . ° d ONLN d o < Ç ( ú ZPR 20 - LaserWriter ° d ONLN d o Dz )≈Driver Surprises in 5.0 and ° d ONLN d 0 Å < î q ( Æ ZNewer
° d ONLN d 6 ì < ¢ s *Printing
° d ONLN d @ Æ < ∫ t * Revised by: ° d ONLN d L Æ Ñ ∫9 )H!Mary Burke & Scott “Zz” Zimmerman ° d ONLN d n Æ∏ ∫˛ ( ÷÷
February 1990 ° d ONLN d | ∫ < Δ q ( ‚ Z Written by: ° d ONLN d à ∫ Ñ Δ Ò )HScott “Zz” Zimmerman ° d ONLN d ù ∫À Δ˛ ( ‚È
April 1988 ° d ONLN d ® “ < fi‚ ( ˙ ZXThis Technical Note describes some changes in version 5.0 and later LaserWriter drivers. ° d ONLN d fi < Í ’ * Changes since April 1988: ° d ONLN d fi ’ Í∫ )ô/ Described a bug in 5.x which is fixed in 6.0 ° d ONLN dI fi∫ Ͳ )Âand later, and ° d ONLN dX Í < ˆI ( Z;reiterated a warning about storing fonts in an application. ! X! ° d ONLN dî <} *%CWith the release of LaserWriter 5.0 and background printing, a few ° d ONLN d◊}˛ (7õchanges had to be made to ° d ONLN dÒ <'à (C ZDthe LaserWriter driver. Although these changes were transparent to ° d ONLN d5à'˛ (C¶most applications, some ° d ONLN dM' <3 ü (O Zhave had problems. ° d ONLN da' ü3˛ )cHMost of these problems are related to use of unsupported features. This ° d ONLN d™3 <? ¯ ([ Z+Note details a partial list of the changes.
° d ONLN d÷W <f ê *'
No Mo’ Low
° d ONLN d·r <~ ç *Because of the ° d ONLN dr ç~˛ )QGproblems supporting both the high-level and low-level interfaces in the ° d ONLN d8~ <ä (¶ Z+background, the low-level interface is all ° d ONLN dc~ä˛ )…2but removed. Instead of the low-level calls being ° d ONLN dñã <ó „ (≥ Z$executed by the device driver, the _ ,
Courier ° d ONLN d∫ä „ñ" )ß PrCtlCall ° d ONLN d√ã"ó% )? ° d ONLN dƒã%ó˛ )/procedure converts the call into its high-level ° d ONLN dÙó <£ (ø ZXequivalent before execution. This way, the LaserWriter driver has a common entry point ° d ONLN dLó£˛ (øfor ° d ONLN dP£ <ØC (À Z7both the low-level and high-level interfaces. Because ° d ONLN dá£CØ˛ (Àa'of this conversion, the low-level calls ° d ONLN dØØ <ª v (◊ Z may not be ° d ONLN d∫Ø vª˛ ):Nfaster than using the high-level equivalents. In some cases, they may even be ° d ONLN d ª <« ` („ Zslower. ° d ONLN d” <fl· *XVersion 5.x of the LaserWriter driver also contains a bug with the low-level interface. ° d ONLN di”·fl˛ (˚ˇ If an ° d ONLN dpfl <Î ( Z.application which uses the low-level Printing ° d ONLN dûflβ )◊0Manager interface encounters an error during the ° d ONLN dœÎ <˜‚ ( Z\course of the print job, the LaserWriter driver crashes before the application has a chance ° d ONLN d+΂˜˛ ( to see ° d ONLN d2˜ < Æ ( Zthe error. Because the ° d ONLN dJ˜ Æ˛ )rEerror occurs inside the driver, there is no way for an application to ° d ONLN dê <ú (+ ZKpredict or work around this problem. The only solution to this problem is ° d ONLN d€ú˛ (+∫to use the high-level ° d ONLN dÒ <Ö (7 ZHPrinting Manager interface or to upgrade to version 6.0 or later of the ° d ONLN d9Ö˛ (7£LaserWriter driver which ° d ONLN dR <' Ä (C Zfixes this bug.
° d ONLN db? <N œ *'Are You Convertible?
° d ONLN dwZ <fO *8Whereas the conversion of the low-level calls should be ° d ONLN dØZOf˛ (Çm$transparent, the conversion routines ° d ONLN d‘f <rñ (é ZEmake some assumptions. The conversion routines require a context in ° d ONLN dfñr˛ (é¥which to operate; the ° d ONLN d/r <~ (ö Z+Printing Manager maintains a certain state ° d ONLN dZr~˛ )”,while executing commands, and the conversion ° d ONLN dá~ <ä/ (¶ Z2routines need access to this state to perform the ° d ONLN dπ~/ä˛ )Û(conversion. To provide this context, an ° d ONLN d‚ä <ñ≥ (≤ ZLapplication must have opened a document and a page. This requirement means ° d ONLN d .ä≥ñ˛ (≤—that the original ¡ X¡
(÷ Z5PR 20 - LaserWriter Driver Surprises in 5.0 and Newer (÷1 ) of 4 (Ï Z M.PR.LaserWriterDriverSurprise ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø˛ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )> *=method of using the low-level interface, which is documented ° d ONLN d = > )K ( E\in ° d ONLN d @ K )ù )
Inside Macintosh ° d ONLN d P ù )÷ )R , Volume II ° d ONLN d [ ÷ )⁄ )9- ° d ONLN d \ ) 5 ( Q 62164, no longer works, as in the following example: ,
Courier
° d ONLN d ê A < L s +$ PrDrvrOpen; ° d ONLN d ù K < V ı *
%PrCtlCall(iPrDevCtl, lPrReset, 0, 0); ° d ONLN d ƒ U < ` » *
{ Send data to be printed. } ° d ONLN d ‚ _ < j ˇ *
'PrCtlCall(iPrDevCtl, lPrPageEnd, 0, 0); ° d ONLN d i < t x *
PrDrvrClose;
° d ONLN d ã ˝ ( ß 61Instead, an application should use the following:
° d ONLN dK ó < ¢ s +$ PrDrvrOpen; ° d ONLN dX ° < ¨ ˇ *
'PrCtlCall(iPrDevCtl, lPrDocOpen, 0, 0); ° d ONLN dÅ ´ < ∂ *
(PrCtlCall(iPrDevCtl, lPrDocClose, 0, 0); ° d ONLN d ” < fi x *
PrDrvrClose;
° d ONLN d+ È ıπ ( 6YThis method provides the Printing Manager with the context it needs to convert the calls.
° d ONLN dÖ
ÿ *'Really Unsupported Features
° d ONLN d°) 5 Â *$Sending data to the printer between ° d ONLN d≈) Â5 ˝ )Õthe ° d ONLN d…( ˝4C )
_PrOpenDoc ° d ONLN d”)C5a )F or ° d ONLN d◊(a4ß )
lPrDocOpen ° d ONLN d·)ß5⁄ )F and the ° d ONLN dÍ5 A e (^ 6 _PrOpenPage ° d ONLN dı6 eB y )M or ° d ONLN d˘5 yA Δ ) lPrPageOpen ° d ONLN d6 ΔB⁄ )M6 calls is not currently, and has never been supported. ° d ONLN d<B NW (j 6DLaserWriter drivers prior to 5.0 interpreted this data, but 5.0 and ° d ONLN dÄBWN⁄ (ju later drivers ignore it. To ° d ONLN dùN Z Á (v 6+download an application-specific PostScript
° d ONLN d»N ÁV Ì (s®
° d ONLN d…N ÌZæ +, dictionary as a header with each document, ° d ONLN dıNæZ⁄ )—Apple ° d ONLN d˚[ g · (É 6*recommends that the application provide a ° d ONLN d%Z ·f )…'PREC' ° d ONLN d+[ gF )*
resource of ° d ONLN d8ZFfi );ID = ° d ONLN d=Zif~ )#103 ° d ONLN d@[~g⁄ ), as is described in ° d ONLN dUg s ) (è 6the ° d ONLN dYg )s ì )LaserWriter Reference ° d ONLN dng ìs ó )j.
° d ONLN dpã ö ß (∂ 6A Little Less Control
° d ONLN dܶ ≤à *NFour of the six printer control calls originally supported by the LaserWriter ° d ONLN d‘¶à≤⁄ (Œ¶driver have been ° d ONLN dÂ≤ æ ç (⁄ 6discontinued due to lack ° d ONLN d˛≤ çæ⁄ )uDof use and difficulty supporting with background printing. The four ° d ONLN dCæ ÷ (Ê 6'calls which follow were only supported ° d ONLN djæ ÷ ⁄ )æ4by the LaserWriter driver and only documented in the ° d ONLN dü ÷ ® (Ú 6 LaserWriter Reference Manual ° d ONLN dª ®÷ ´ )ê:
° d ONLN dø‚ `Ì à ( ~°•° fill ° d ONLN d»‚ ®Ì ⁄ )H
°•° hexBuf ° d ONLN d”‚ Ì" )H
°•° printR ° d ONLN dfi‚8Ìj )H
°•° printF
° d ONLN dÈ˘ y (! 6In addition to these ° d ONLN d˛˘ y ™ )a calls, the ° d ONLN d ¯ ™ ‘ )1stdBuf ° d ONLN d˘ ‘⁄ )*6 call is also affected. There are two versions of the ° d ONLN dF B (. 6stdBuf ° d ONLN dL B Ì )*% call depending upon the sign of the ° d ONLN dq Ì )´bytes ° d ONLN dvV )# parameter. If ° d ONLN dÜVy )Fbytes ° d ONLN dãy| )# ° d ONLN då|⁄ )is negative, the text ° d ONLN d¢ X (; 6passed to the ° d ONLN d∞ X Ç )@stdBuf ° d ONLN d∂ Ç ( )*& call is converted to PostScript text ° d ONLN d‹( ⁄ )¶%before being sent to the LaserWriter. ° d ONLN d + m (G 6This conversion ° d ONLN d m+⁄ )UFmeans that special PostScript characters in the text are preceded by a ° d ONLN dZ+ 7 ü (S 6 PostScript escape character. ° d ONLN dw+ ü7⁄ )áA In addition, characters with an ASCII value greater than 128 are ° d ONLN dπ7 C´ (_ 6Vconverted to octal before being sent to the LaserWriter. This version of the call is ° d ONLN d7´C⁄ (_… no longer ° d ONLN dC O K (k 6
supported. ° d ONLN d$[ g P *
If the bytes ° d ONLN d1[ Pg⁄ )8Vparameter is positive, the text passed to the call is sent directly to the LaserWriter ° d ONLN dàg s… (è 6\without conversion and interpreted as PostScript instructions. This version of the call is ° d ONLN d‰g…s⁄ (èÁstill ° d ONLN dÍs é (õ 6Osupported, but there is one more problem. When an application first opens the ° d ONLN d 9sé⁄ (õ¨low-level driver ° d ONLN d JÄ å / (® 6(via ° d ONLN d O /ã | ) _PrDrvrOpen ° d ONLN d ZÄ |å} )M3) with background printing enabled, no clip region ° d ONLN d çÄ}å⁄ (®õis defined. If the ¡ 4¡˘
(÷ 65PR 20 - LaserWriter Driver Surprises in 5.0 and Newer (÷‡2 ) of 4 (Ï 6 M.PR.LaserWriterDriverSurprise ˇ¶ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -‚
February 1990 / X /
° d ONLN d < *e ( F ZAapplication then begins sending PostScript to the driver via the ,
Courier ° d ONLN d A e )è ( FÉstdBuf ° d ONLN d G è *ˆ )* call, all of the output ° d ONLN d ` ˆ *˛ )gis ° d ONLN d c * < 6 ˇ ( R Z*clipped, and only a blank page is printed. ° d ONLN d é B < N0 *4To prevent this problem, the application must force ° d ONLN d ¬ B0 N˛ )Ù,a clip region to be sent to the LaserWriter. ° d ONLN d N < Z ( v Z]The region is sent by the driver when it receives its first drawing command. Unfortunately, ° d ONLN dM N Z˛ ( vthe ° d ONLN dQ [ < g ¬ ( É Z driver does not consider the ° d ONLN dn Z ¬ f Ï )ÜstdBuf ° d ONLN dt [ Ï g )* call ° d ONLN dz [ g˛ )2to be a drawing command. To force the clip region ° d ONLN d≠ h < t ( ê Z,on the printer, the application can use the ° d ONLN dŸ g sF )ƒ
iPrBitsCtl ° d ONLN d„ hF tâ )F call to print a ° d ONLN dÙ hâ t˛ )Csmall bitmap outside the ° d ONLN d
t < Ä ‘ ( ú Z"printable area of the page. This ° d ONLN d/ t ‘ IJ )ò?call does not have any effect on the document, but it fires the ° d ONLN do Ä < å ’ ( ® Z bottleneck routine and causes ° d ONLN dç Ä ’ å˛ )ô:a definition of the clip region. Since the clip region is ° d ONLN d» ç < ô ´ ( µ Zreinitialized at each call ° d ONLN d„ ç ´ ô ∏ )oto ° d ONLN dÊ å ∏ ò )
lPrPageOpen ° d ONLN dÒ ç ô˛ )M4, the application should send the bitmap once at the ° d ONLN d& ö < ¶ ` ( ¬ Z start of ° d ONLN d/ ö ` ¶s )$;each page. If any other printer control calls precede the ° d ONLN dj ôs •ù ( ¬ëstdBuf ° d ONLN dp öù ¶˛ )* call, the application ° d ONLN dá ¶ < ≤ ⁄ ( Œ Z!does not need to send the bitmap.
° d ONLN d¡ Ê < Ú S *The ° d ONLN d≈  S Ò ¬ )'PREC' ID = 201 ° d ONLN d‘ Ê ¬ Úö )o& mechanism only works when background ° d ONLN d˙ Êö Ú˛ )ÿprinting is disabled. ° d ONLN d Ú < ˛ ( ZZThis limitation is because of difficulties finding the resource under MultiFinder. Since ° d ONLN dk Ú ˛˛ (the ° d ONLN do ˛ <
u (& Z option only ° d ONLN d{ ˛ u
˛ )9Pworks in the foreground, and since there is no way for an application to know if ° d ONLN dÃ
<Æ (2 ZObackground printing is enabled, an application should avoid using this feature.
° d ONLN d . <= ‰ *'Fonts In An Application?
° d ONLN d5I <U s *
There are ° d ONLN d?I sU˛ )7Itwo problems when printing application fonts with the LaserWriter driver. ° d ONLN däU <a ç (} ZApplication fonts ° d ONLN dõU ça
)Q are fonts that are stored in ° d ONLN dπU
a˛ )Ä4the resource fork of the application’s resource file ° d ONLN dÓa <m (â Z2rather than being stored in the System file. The ° d ONLN d a m˛ )„.first problem occurs when the application font ° d ONLN dOm <y Ù (ï Z'has the same name as the application’s ° d ONLN dvm Ùy˛ )∏;resource file. If this is the true, the LaserWriter driver ° d ONLN d≤y <Öπ (° ZWincorrectly assumes that the application’s resource file is a font file, and closes it ° d ONLN d yπÖ˛ (°◊after using the ° d ONLN dÖ <ë (≠ Z)font. To solve this problem, developers ° d ONLN dBÖë˛ )»1should make sure the name of the application font ° d ONLN dtí <û h (∫ Z (i.e., the ° d ONLN dë hù í ),'FOND' ° d ONLN dÖí íû… )*D resource) is different from the name of the application’s resource ° d ONLN d…í…û˛ (∫Á file. Since ° d ONLN d÷û <™Î (Δ Z[the application can still be renamed by the user, developers should try to select a unique ° d ONLN d1ûΙ˛ (Δ font ° d ONLN d6™ <∂ ‡ (“ Z!name. If the font name does not ° d ONLN dW™ ‡∂˛ )§7appear in a font menu, developers can simply append the ° d ONLN dè∑ <√ (fl Zapplication’s ° d ONLN dù∑ √á )C2creator string onto the desired font name (i.e., ' ° d ONLN dœ∂ᬲ (fl•MyApplicationFont ° d ONLN d·√ <œ _ (Ï ZZZAP' ° d ONLN dʃ _– g )#). ° d ONLN dÈ‹ <Ë ü ( ZThe second problem ° d ONLN d¸‹ ü˲ )cGwith application fonts only occurs when background printing is enabled. ° d ONLN d EË <Ù ô ( ZWhen a print job is ° d ONLN d YË ôÙ˛ )]Jperformed in the background, the LaserWriter driver writes all of the data ° d ONLN d §Ù < ( Z*to be printed into a file (called a spool ° d ONLN d ŒÙ ˛ )¥;file) for printing at a later time by Print Monitor. Since ° d ONLN d
< ‡ (( Z"the LaserWriter driver has no way ° d ONLN d
, ‡ ˛ )§<of knowing when the file will actually be printed, it cannot ° d ONLN d
i < Ê (4 Z'assume that the application will still ° d ONLN d
ê Ê˛ )™:be open when the job is printed. This is a problem if the ° d ONLN d
À <$Œ (@ ZSapplication contains application fonts that Print Monitor needs at print time. To ° d ONLN d Œ$˛ (@Ï
solve this ° d ONLN d )$ <0π (L ZOproblem, the LaserWriter driver must determine whether the fonts needed by the ° d ONLN d x$π0˛ (L◊application are ° d ONLN d à0 <<Ç (X ZLresident in the System file or in the application file. If they are in the ° d ONLN d ‘0Ç<˛ (X† application file, the driver ° d ONLN d Ò< <HØ (d ZQmust copy them into the spool file so they are available to Print Monitor. This ° d ONLN d B<ØH˛ (dÕpractice can lead ° d ONLN d TH <Tù (p ZMto very large spool files, as well as a significant loss of performance when ° d ONLN d °HùT˛ (pªbackground printing ° d ONLN d µT <`~ (| ZFis enabled. To solve these and other user interface problems related ° d ONLN d ˚T~`˛ (|úto application fonts, Apple ° d ONLN d
` <lÍ (à Z\strongly recommends that developers ship custom application fonts as suitcase files for the ° d ONLN d
s`Íl˛ (àuser ° d ONLN d
xl <x Ω (î Z to install in the System file. ¡ X¡
*B5PR 20 - LaserWriter Driver Surprises in 5.0 and Newer (÷3 ) of 4 (Ï Z M.PR.LaserWriterDriverSurprise ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d , ° *Headin’ For Trouble
° d ONLN d 8 D ‡ *+There is a minor bug in version 5.0 of the ° d ONLN d ? 8 ‡ D⁄ )»6LaserWriter driver that only affects applications that ° d ONLN d v D P ( l 6parse the PostScript ° d ONLN d ã D P⁄ )g@header downloaded by the driver with each document. This header ° d ONLN d à P \ fi ( x 6'contains some PostScript comments that ° d ONLN d Û P fi \⁄ )Δ2provide information about the current job. One of ° d ONLN d& ] i t ( Ö 6these comments is ,
Courier ° d ONLN d8 \ t h ÷ )\IncludeProcSet ° d ONLN dF ] ÷ ia )b . This comment takes three ° d ONLN db ]a i⁄ )ãarguments: a PostScript ° d ONLN d{ i u ı ( ë 6-dictionary name, a major version number, and ° d ONLN d® i ı u⁄ )›.a minor version number. In version 4.0 of the ° d ONLN d◊ u ÅB ( ù 6?LaserWriter driver, the comment line looked like the following:
° d ONLN d ç < ò ˙ +$&%% IncludeProcSet: (Appledict md) 65 0
° d ONLN d? £ Ø ˇ ( À 61Unfortunately, in version 5.0 of the LaserWriter ° d ONLN dp £ ˇ Ø⁄ )Á,driver, the last argument was removed. This ° d ONLN dù Ø ª ( ◊ 63caused the comment line to look like the following:
° d ONLN d“ « < “ Î +$#%% IncludeProcSet (Appledict md) 66
° d ONLN dˆ › È9 ( 6<Since Adobe defined the comment to take three arguments, it ° d ONLN d2 ›9 È⁄ (W#is reasonable for applications that ° d ONLN dV È ıà ( 6Rparse the comments to expect three arguments; therefore, version 5.1 and later of ° d ONLN d® Èà ı⁄ (Íthe ° d ONLN d¨ ı = ( 6>LaserWriter driver contain the correct version of the comment:
° d ONLN dÏ
< ı +$%%% IncludeProcSet (Appledict md) 67 0
° d ONLN d/ > ç (Z 6No Go With Zero
° d ONLN d"J VP *?Some applications want to force a font to be downloaded to the ° d ONLN daJPV⁄ (rn LaserWriter without actually ° d ONLN d~V bd (~ 6Iprinting characters with the font. This can be done in three easy steps: ° d ONLN d»n z " *1. ° d ONLN dÀn *z ∑ ) Save the current pen position. ° d ONLN dÍz Ü " (¢ 62. ° d ONLN dÌz *Ü0 )7Use any text drawing routine to draw a space character. ° d ONLN d%Ü í " (Æ 63. ° d ONLN d(Ü *í Î )(Move the pen back to the saved position. ° d ONLN dQü ´ ä (« 6Some applications use ° d ONLN dgû ä™ ◊ )r _DrawString ° d ONLN drü ◊´ )M with a ° d ONLN dzü ´e ))empty string (e.g., ° d ONLN déûe™« )eDrawString('') ° d ONLN dúü«´⁄ )b) to ° d ONLN d°´ ∑t (” 6Hforce the font downloading. Although this worked in LaserWriter drivers ° d ONLN dÈ´t∑⁄ (”íup to 5.0, these calls ° d ONLN d ∑ √í (fl 6Qare ignored by the 5.1 and later drivers. The main reasons for this change were ° d ONLN dQ∑í√⁄ (fl∞optimization of ° d ONLN da√ œ (Î 67performance and a reduction in the size of spool files. ° d ONLN dôÛ ˇ Ç *0Further Reference: 4 ˘ ° d ONLN d¨ * . +
• ° d ONLN dÆ < ç )Inside Macintosh ° d ONLN dæ ç N )Q&, Volumes II & V, The Printing Manager ° d ONLN d * . (4 H• ° d ONLN dÁ < à ) LaserWriter Reference Manual ° d ONLN d$ 0\ (L 6CPostScript is a registered trademark of Adobe Systems Incorporated. ¡ 4¡˘
*ä5PR 20 - LaserWriter Driver Surprises in 5.0 and Newer (÷‡4 ) of 4 (Ï 6 M.PR.LaserWriterDriverSurprise ˇV ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åö ( õ Z)PR 21 - Pictures and the Printing Manager
° d ONLN d * Ä < è s *Printing
° d ONLN d 4 õ < ß q * Written by: ° d ONLN d @ õ Ñ ß Ã )H Zz Zimmerman ° d ONLN d M õÀ ߲ ( √È
April 1991 ° d ONLN d X ≥ < ø◊ ( € ZUThis technical note described some problems and features of using Quickdraw pictures ° d ONLN d ≠ ≥◊ ø˛ ( €ıwith the ° d ONLN d ∂ ø < À ò ( Á ZPrinting Manager. ° d ONLN d … ø ò À˛ )\JIn general, if your application prints Quickdraw pictures, you should read ° d ONLN d À < ◊ h ( Û Z
this note. X
° d ONLN d ¸ < è *4 Introduction
° d ONLN d, <#$ *0Most applications support Quickdraw pictures to ° d ONLN d\$#˛ )Ë+some degree. They will allow you to import ° d ONLN dà# </ j (K Z
or export ° d ONLN dí# j/˛ ).Tpicture files, as well as using the PICT resource format on the clipboard to support ° d ONLN dÁ/ <; \ (W ZCut & ° d ONLN dÌ/ \;˛ ) VPaste with other applications. Unfortunately, there are some problems that occur with ° d ONLN dD; <GP (c Z=pictures at print time, and that's what I want to cover here.
° d ONLN dÇ_ <n ∞ *'You PICT When?
° d ONLN dëz <Ü Ò *"One of the problems that comes up ° d ONLN d≥z Òܲ )µ3at print time is the use of picture comments. Some ° d ONLN dÁÜ <í w (Æ Z
applications ° d ONLN dÙÜ wí˛ );Ustore their data in a native format, and only create pictures at print time to enable ° d ONLN dJí <û (∫ Z/the use of picture comments. For each page of ° d ONLN dyí û˛ )‡-the document, they open a new picture, record ° d ONLN dßû <™ Ñ (Δ Zthe Quickdraw ° d ONLN dµû Ñ™˛ )HLcalls that described the document, along with any picture comments they want ° d ONLN d™ <∂ ¥ (“ Zto use, and finally close ° d ONLN d ™ ¥∂˛ )xCthe picture. When this is done, they call DrawPicture to print the ° d ONLN d`∂ <¬Ñ (fi ZGpicture, and then start the whole process over again for the next page. ° d ONLN d®Œ <⁄/ *.This method is supported and fully compatible ° d ONLN d÷Œ/⁄˛ )Û'with future system software, but is not ° d ONLN d˛⁄ <Ê ˇ ( Z'required. The Printing Manager spools ° d ONLN d%⁄ ˇÊ˛ )√1each page of a document into a Quickdraw picture. ° d ONLN dXÊ <Úå ( ZESince the Printing Manager already has a picture open, it is totally ° d ONLN dùÊåÚ˛ (™legal to send a picture ° d ONLN dµÚ <˛ Á ( Z"comment (via the PicComment call) ° d ONLN d◊Ú Á˛˛ )´6in between calls to PrOpenPage and PrClosePage without ° d ONLN d˛ <
(& Z%having them recorded in a picture. ° d ONLN d3˛
˛ ) -The Printing Manager has already replaced the ° d ONLN da
< ’ (2 Z StdComment procedure with its ° d ONLN d
’˛ )ô:own anyway, so the PicComment call will be intercepted and ° d ONLN d∫ <"í (> ZIsupported correctly by the Printing Manager. If the only reason you are ° d ONLN dí"˛ (>∞recording into pictures ° d ONLN d" <.ñ (J ZBis so that you can use PicComments, you can avoid the overhead at ° d ONLN d]"ñ.˛ (J¥print time by simply ° d ONLN dr. <: œ (V Z sending the comments directly.
° d ONLN dëR <a ¥ *'Feeling PICT On?
° d ONLN d¢m <y *-Even if you aren't sending picture comments, ° d ONLN dœm y˛ )·/you may still need to create a picture at print ° d ONLN dˇy <Ö> (° Z9time. In general, you should try to create any pictures ° d ONLN d8y>Ö˛ (°\'you need prior to calling PrOpen. This ° d ONLN d`Ö <ëP (≠ Z8is because there is no way to predict how much memory a ° d ONLN dòÖPë˛ (≠n'particular printer driver will require. ¡ X¡
(÷ Z)PR 21 - Pictures and the Printing Manager (÷1 ) of 4 (Ï ZM.PR.PictAndPrinting ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) *3Instead, you need to make as much memory available ° d ONLN d 3 )⁄ )ˇ*as possible. If you are creating pictures ° d ONLN d ^ ) 57 ( Q 6:with the Printing Manager open, the chances are good that ° d ONLN d ò )7 5⁄ ( QU you are using memory you can't ° d ONLN d ∑ 5 A c ( ] 6afford to waste. ° d ONLN d » M Y ¶ * If you need to create a picture ° d ONLN d Ë M ¶ Y⁄ )é<with the Printing Manager open, and memory is not a problem, ° d ONLN d% Y e - ( Å 6you ° d ONLN d) Y - e⁄ )Zshould still be aware of some potential problems. First of all, keep in mind the Printing ° d ONLN dÑ e qi ( ç 6FManager receives data from the application by replacing the Quickdraw ° d ONLN d ei q⁄ ( çáGrafProcs stored in the ° d ONLN d‚ q }S ( ô 6<GrafPort returned by PrOpenDoc. One of these procedures is ° d ONLN d qS }⁄ ( ôqthe StdComment procedure ° d ONLN d7 } â 8 ( • 6which ° d ONLN d= } 8 â⁄ ) Vis called each time the application calls the Quickdraw PicComment routine. Since the ° d ONLN dî â ï £ ( ± 6Printing Manager has these ° d ONLN dØ â £ ï⁄ )ã>routines patched, creating a picture in the Printing Manager's ° d ONLN dÓ ï ° ¸ ( Ω 6%GrafPort can cause problems. If you ° d ONLN d ï ¸ °⁄ )‰&must create a picture between calls to ° d ONLN d: ° ≠∞ ( … 6SPrOpenPage/PrClosePage, you should be sure to set the port to a standard Quickdraw ° d ONLN dç °∞ ≠⁄ ( …ŒGrafPort ° d ONLN dñ ≠ π 9 ( ’ 6before ° d ONLN dù ≠ 9 π⁄ )!Scalling OpenPicture. Any GrafPort that was created by Quickdraw (as opposed to the ° d ONLN dÒ π ≈ ∏ ( · 6!Printing Manager) will work fine. ° d ONLN d — ›é *PIf you do create a picture at print time, you may experience a syndrome we call ° d ONLN dc —é ›⁄ ( ˘¨'floating picture ° d ONLN du › Èœ ( 6Scomments'. That is, calls made by your application to the PicComment routine will ° d ONLN d» ›œ È⁄ (Ìbe ° d ONLN dÀ È ı≠ ( 6Srecorded in a different order than you made them. This will usually cause them to ° d ONLN d È≠ ı⁄ (À
effect the ° d ONLN d) ı ® ( 6 wrong part of the picture, and ° d ONLN dH ı ®⁄ )ê@lead to endless confusion. The best solution to this problem is ° d ONLN dâ
() 67to create any pictures that your application will need ° d ONLN d¿
3 )˜before ° d ONLN dΔ3
Δ )$ opening the Printing Manager.
° d ONLN dÂ% 4G (P 6,Scaling Pictures - Mountains from Mole Hills
° d ONLN d@ Ll *DAnother problem is a basic problem with pictures that seems to show ° d ONLN dV@lL⁄ (häup more at print time. ° d ONLN dnL X 0 (t 6The ° d ONLN drL 0X⁄ )Rproblem concerns the scaling of pictures using the destination rectangle passed to ° d ONLN d≈X d} (Ä 6JDrawPicture. This method will work for most pictures, but problems arise ° d ONLN dX}d⁄ (Äõwith more complex ° d ONLN d!d p  (å 6/pictures, and for pictures that contain text. ° d ONLN dPd Âp⁄ )Õ0The problem is the method that Quickdraw uses to ° d ONLN dÅp | ò (ò 6 scale the text stored within ° d ONLN dûp ò|⁄ )ÄCpictures. When scaling, Quickdraw tries to handle the text scaling ° d ONLN d‚| à; (§ 6>intelligently by changing the size of the font being used, as ° d ONLN d |;à⁄ (§Y!opposed to just scaling the bits. ° d ONLN dCà î£ (∞ 6TUnfortunately, the widths used by bitmapped fonts are not always linear (ie. the 12 ° d ONLN dóà£î⁄ (∞¡ point width ° d ONLN d£î † (º 66isn't exactly 1/2 of the 24 point width). Because of ° d ONLN dŸî†⁄ )ˆ*this, you can run into problems with lines ° d ONLN d † ¨b (» 6Iof text getting slightly longer or shorter as the picture is scaled. In ° d ONLN d M†b¨⁄ (»Ämany cases, the error is ° d ONLN d f¨ ∏∏ (‘ 6Uinsignificant, but if you are trying to draw a line of text that fits exactly into a ° d ONLN d ª¨∏∏⁄ (‘÷box (a ° d ONLN d ¬∏ ƒ Ω (‡ 6#spreadsheet cell for example), you ° d ONLN d Â∏ Ωƒ⁄ )•;might be surprised to see the line of text extending beyond ° d ONLN d
!ƒ – ª (Ï 6#the box when the picture is scaled. ° d ONLN d
E‹ Ë ú *There can also be problems ° d ONLN d
`‹ úË⁄ )Ñ?when using certain picture comments or imbedded PostScript. In ° d ONLN d
†Ë Ù ö ( 6the case of the TextCenter ° d ONLN d
ªË öÙ⁄ )ÇApicture comment, you specify an offset to the center of rotation. ° d ONLN d
˛Ù ( 68This offset is usually based on the metrics of the font ° d ONLN d 6Ù ⁄ ( >&being used. If you scale the picture, ° d ONLN d ] ” (( 6%Quickdraw decides to use a different ° d ONLN d Ç ” ⁄ )ª5font, and the offset you originally specified will be ° d ONLN d ∏ E (4 6
incorrect. ° d ONLN d √$ 0 é *The easiest way to solve ° d ONLN d ‹$ é0⁄ )vGthese problems is to scale the picture yourself. Especially if you are ° d ONLN d $0 <∑ (X 6Ztrying to scale by a large amount. For example, some applications create a picture at 72 ° d ONLN d ~0∑<⁄ (X’dpi (ie. ° d ONLN d á< H ÿ (d 6)dots per inch), and then scale it to 288 ° d ONLN d ∞< ÿH⁄ )¿5dpi for printing by simply increasing the destination ° d ONLN d ÊH T ˙ (p 6.rectangle by 4x. This is asking a lot of the ° d ONLN d
H ˙T⁄ )‚,system, and will result in the text problems ° d ONLN d
AT `Ö (| 6Pdescribed above. Instead, you should either draw the picture into its original ° d ONLN d
ëTÖ`⁄ (|£frame, and let the ° d ONLN d
§` lé (à 6RPrinting Manager handle scaling it to the resolution of the device, or handle the ° d ONLN d
ˆ`él⁄ (à¨scaling yourself ° d ONLN dl x» (î 6[by parsing the picture and playing it back opcode by opcode instead of calling DrawPicture. ¡ 4¡˘
*B2 ) of 4 (÷M)PR 21 - Pictures and the Printing Manager +NM.PR.PictAndPrinting ˇ2 ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -
April 1991 / X /
° d ONLN d < ) Ÿ ( E Z!One last thing to watch for when ° d ONLN d ! Ÿ )˛ )ù@scaling pictures is integer overflows. It's usually pretty rare ° d ONLN d b ) < 51 ( Q Z4that you will overflow a coordinate when creating a ° d ONLN d ñ )1 5˛ )ı+Quickdraw picture, but it is not so hard to ° d ONLN d ¬ 5 < A å ( ] Zdo when scaling ° d ONLN d “ 5 å A˛ )PKa picture. For example, some applications will draw something offscreen to ° d ONLN d A < M É ( i Zmake sure the ° d ONLN d, A É M˛ )GMPrinting Manager has configured the clip region and other related structures. ° d ONLN d{ M < YÈ ( u ZVThey usually do this by moving the cursor to (-32767,-32767), and then draw a pixel. ° d ONLN d— MÈ Y˛ ( uThis ° d ONLN d÷ Y < e[ ( Å Z=works fine to initialize the Printing Manager, and the pixel ° d ONLN d Y[ e˛ ( Åy"isn't actually seen on the output. ° d ONLN d7 e < q§ ( ç ZNThe problem occurs when you try to scale this picture. If you try to make it ° d ONLN dÖ e§ q˛ ( ç¬bigger, Quickdraw ° d ONLN dó q < }¶ ( ô ZIwill adjust to coordinate (-32767,-32767) which will end up overflowing. ° d ONLN d‡ q¶ }˛ ( ôƒ The only way to ° d ONLN dÒ } < âÁ ( • Z^solve these problems is to look for these kinds of operations in the picture before trying to ° d ONLN dO }Á Ⲡ( •scale ° d ONLN dU â < ï ú ( ± Zit with DrawPicture.
° d ONLN dj ≠ < ºó *'3Pictures Within Pictures–Is Nesting the Best Thing?
° d ONLN dû » < ‘£ *LOne cool feature of Quickdraw pictures is the ability to nest them easily. ° d ONLN dÍ »£ ‘˛ ( ¡Basically, you can ° d ONLN d˝ ‘ < ‡ R ( ¸ Zcall ° d ONLN d ‘ R ‡˛ )POpenPicture, and then call DrawPicture with multiple pictures, and when you call ° d ONLN dS ‡ < Ïπ ( ZMClosePicture, they will all have been recorded into one picture. Very cool. ° d ONLN d† ‡π Ï˛ (◊ The problem ° d ONLN d≠ Ï < ¯ _ ( Zcomes ° d ONLN d≥ Ï _ ¯˛ )#Lwhen you start using the Begin/End form of picture comments. There are some ° d ONLN d ¯ < â ( Zcomments like ° d ONLN d ¯ Ⲡ)MFPostScriptBegin/PostScriptEnd, and TextBegin/TextEnd that have a begin ° d ONLN dU < Ç (, Z
comment that ° d ONLN db Dz )FEis followed by an end comment. When using these comments, it is very ° d ONLN d® < Ì (8 Z%important to make sure that you have ° d ONLN dÕ Ì ˛ )±9an end for each begin that you have sent. If the nesting ° d ONLN d <(ê (D ZJgets off, you will, at the least, get incorrect output, though it is more ° d ONLN dQ ê(˛ (DÆlikely that the Printing ° d ONLN dj( <4 i (P ZManager ° d ONLN dr( i4˛ )-Twill actually crash. If your application is generating picture comments, it is very ° d ONLN d«4 <@ (\ Z-simple to make sure that you have an end for ° d ONLN dÙ4@˛ )÷0each begin. But when nesting a picture that you ° d ONLN d%@ <Lj (h Z@have imported from another application, it is important to know ° d ONLN de@jL˛ (hà how its comments will interact ° d ONLN dÑL <X s (t Z with yours. ° d ONLN dêd <p’ *UIn most cases, you can simply call DrawPicture to render the picture to the Printing ° d ONLN dÂd’p˛ (åÛManager ° d ONLN dÌp <|Î (ò Z\and you don't have to worry. But if you are creating a picture for export, you may have to ° d ONLN dIpÎ|˛ (ò nest ° d ONLN dN| <à» (§ ZXmultiple pictures from multiple creators into the same picture to be exported. If this ° d ONLN d¶|»à˛ (§Ê is the case, ° d ONLN d≥à <î R (∞ Zit is ° d ONLN dπà Rî˛ )Qimportant to make sure that all of your begin comments have matching end comments ° d ONLN d î <† ` (º Zbefore ° d ONLN d î `†Ä )$A attempting to insert another picture. If this is done, you can ° d ONLN d RîƲ (ºûinsert the imported picture ° d ONLN d n† <¨” (» ZWwithout having to worry about the comments it contains. If all of your begin/ends are ° d ONLN d ≈†”¨˛ (»Òmatched, ° d ONLN d Œ¨ <∏^ (‘ Z?you can assume that the imported picture will be just as valid. ° d ONLN d
ƒ <– ° *On the other hand, if ° d ONLN d
$ƒ °–˛ )eGyou have a begin comment, and want to insert a picture before inserting ° d ONLN d
l– <‹ M (¯ Zthe ° d ONLN d
p– M‹˛ )Yappropriate end comment, you must parse the picture to be inserted to make sure it is not ° d ONLN d
‹ <Ë∏ ( ZRusing the same comment pair. If it is, and you insert it, you will have problems. ° d ONLN d Ù < ì *So make sure that ° d ONLN d /Ù ì ˛ )WLall your begins and ends are matched, and don't try to insert other pictures ° d ONLN d | < ¯ (( Z&between begin/end pairs of comments. ° d ONLN d ¢ ¯ ˛ )º7If you find that you have to insert a picture between a ° d ONLN d ⁄ <á (4 ZFpair of begin/end comments, you must parse the picture to be inserted ° d ONLN d Რ(4•to make sure that it does ° d ONLN d : <$ ¡ (@ Znot use the same comments.
° d ONLN d U< <K *' Penalty for Quickdraw - Clipping
° d ONLN d vW <c */Here's a subtle fact about Quickdraw pictures. ° d ONLN d •Wc˛ )fi. If you call OpenPicture, and then record some ° d ONLN d ‘c <o> (ã Z7drawing operations, and you don't explicitly specify a ° d ONLN d
c>o˛ (ã\'clipping region, Quickdraw will specify ° d ONLN d
3o <{ó (ó ZMone for you. In fact, Quickdraw will use the last clip region stored in the ° d ONLN d
Äoó{˛ (óµGrafPort that you are ° d ONLN d
ñ{ <áo (£ Z>using when you call OpenPicture. This has been a surprise to ° d ONLN d
‘{oᲠ(£çmany a developer when they ¡ X¡
(÷ Z)PR 21 - Pictures and the Printing Manager (÷3 ) of 4 (Ï ZM.PR.PictAndPrinting ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )s *Krecord a picture, and a big piece of it ends up missing when they draw it. ° d ONLN d K s )⁄ ( Eë This isn't specific to ° d ONLN d c ) 5Õ ( Q 6^print time, it can happen on the screen too, but it happens enough that it's worth mentioning.
° d ONLN d ¬ M \ s *'
D' Resolution
° d ONLN d – h t ® * If you've read Technical Note ° d ONLN d Ó h ® t⁄ )ê<#275, Features of 32 Bit Quickdraw 1.2, you probably noticed ° d ONLN d+ t Ä ( ú 65the new font and resolution information. Basically, ° d ONLN d` t Ä⁄ )˜)fonts are now stored in pictures by name, ° d ONLN dä Ä å… ( ® 6Tnot by ID. This means that fonts stored in pictures will be displayed correctly on ° d ONLN dfi Ä… å⁄ ( ®Áany ° d ONLN d‚ å ò3 ( ¥ 67Macintosh without fonts remapping to other faces. The ° d ONLN d å3 ò⁄ ( ¥Q!other new addition to the picture ° d ONLN d; ò § ( ¿ 6:format is horizontal and vertical resolution information. ° d ONLN du ò §⁄ ( ¿>( Applications that create pictures using ° d ONLN dû § ∞ ˜ ( à 6/the new OpenCPicture call will be able to tell ° d ONLN dÕ § ˜ ∞⁄ )fl.Quickdraw the native resolution of the picture ° d ONLN d¸ ∞ º ¥ ( ÿ 6#data. So if you're a scanner that ° d ONLN d ∞ ¥ º⁄ )ú>is scanning at 200 dpi, you will be able to store your data at ° d ONLN d^ º » ß ( ‰ 6 200 dpi (instead of scaling it ° d ONLN d} º ß »⁄ )è=to 72 dpi first). When an application subsequently opens the ° d ONLN dª » ‘7 ( 6<picture, it can determine the picture's resolution and take ° d ONLN d˜ »7 ‘⁄ ( U!the necessary steps to display it ° d ONLN d ‘ ‡ { ( ¸ 6correctly (ie. scaling ° d ONLN d0 ‘ { ‡⁄ )cGdown for display on the 72 dpi screen, or scaling up for display on 300 ° d ONLN dx ‡ Ï µ ( 6"dpi devices like the LaserWriter).
° d ONLN dõ a *'
Conclusion
° d ONLN d¶ +7 *>Quickdraw pictures can be used successfully at print time, if ° d ONLN d‰ 7+⁄ (GU you avoid the problems described ° d ONLN d+ 7ò (S 6Qabove. Although there is a little overhead required by some of the workarounds, ° d ONLN dV+ò7⁄ (S∂
most are very ° d ONLN dd7 C (_ 6Ksimple to implement, and will help you avoid future compatibility problems. ° d ONLN d∞g s Ç *0Further Reference: í 4í˘ ° d ONLN d√t *Ä . +
• ° d ONLN d≈t <Ä] )8PostScript Language Reference Manual, Adobe Systems Inc. ° d ONLN d˛Ä *å . (® H• ° d ONLN d Ä <å" ),LaserWriter Reference Manual, Addison-Wesley ° d ONLN d-ò §\ (¿ 6CPostScript is a registered trademark of Adobe Systems Incorporated. ¡ 4¡˘
(÷ 64 ) of 4 (÷M)PR 21 - Pictures and the Printing Manager +NM.PR.PictAndPrinting ˇ* ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å Ñ ( õ ZPR 22 - ° d ONLN d n Ñ Å˛ )H+pIdle Proc (or how to let users know what’s ° d ONLN d 4 Ä < ì0 ( ≠ Z going on during print time…)
° d ONLN d Q í < ° s *Printing
° d ONLN d [ ≠ < π q * Written by: ° d ONLN d g ≠ Ñ π )HPete “Luke” Alexander ° d ONLN d } ≠À π˛ ( ’È
April 1991 ° d ONLN d à ≈ < —^ ( Ì Z;This Technical Note discusses how to defensively program a ° d ONLN d √ ≈^ —˛ ( Ì| pIdle procedure to work with the ° d ONLN d ‰ — < ›ß ( ˘ ZRmajority of print drivers in existence today, and how to install it at print time. X
° d ONLN d7 ˆ < è *( Introduction
° d ONLN dD < t *CWhen using a pIdle procedure at print time, there are a few things ° d ONLN dát ˛ (9íthat one should remember to ° d ONLN d£ <) ò (E Zbe compatible with ° d ONLN d∂ ò)˛ )\Lthe printer drivers that are available today. This Technical Note discusses ° d ONLN d) <5Â (Q Z[installing a pIdle procedure at the right time and the things to remember when writing one.
° d ONLN daM <\ ‰ *'Installing The pIdle Proc
° d ONLN d{h <t *SLet's start by installing the pIdle procedure at the right time. You must install ° d ONLN dŒh t˛ (êË
your pIdle ° d ONLN dŸu <Å (ù Z/procedure into the print record before calling ,
Courier ° d ONLN dtÄW )‹ PrOpenDoc ° d ONLN duWÅÖ )?
. If you ° d ONLN duÖÅ˛ ).do not install your pIdle ° d ONLN d5Ç <é à (™ Z procedure before your call to ° d ONLN dSÅ Ãç )ê PrOpenDoc ° d ONLN d\Ç éÇ )?, the printer driver does ° d ONLN dvÇÇé˛ )wnot give the application's ° d ONLN dëé <ö ≈ (∂ ZpIdle procedure any time. ° d ONLN d¨é ≈ö˛ )â=The following code fragments demonstrate installing the pIdle ° d ONLN dÍö <¶ ø (¬ Z procedure in the right place: ° d ONLN d≤ <æ É *
? thePrRecHdl^^.prJob.pIdleProc := @checkMyPrintDialogButton; ° d ONLN d+ <6 *2 thePrPort := PrOpenDoc(thePrRecHdl, NIL, NIL); ° d ONLN d^$ </ P * ° d ONLN db$ P/ \ )<< ° d ONLN dd$ \/∞ ) D more print loop would follow below, see Tech Note #161 for details ° d ONLN d®$∞/º (KŒ>>
° d ONLN d´F <R h (n ZMPW C
° d ONLN d±^ <i H * ° d ONLN d∑^ Hi T ) << ° d ONLN dπ^ Ti® ) D more print loop would appear above, see Tech Note #161 for details ° d ONLN d˝^®i¥ (ÖΔ>> ° d ONLN d r <}Æ (ô ZJ /** Install a pointer to your pIdle proc into your print record. **/ ¡ X¡
*=PPR 22 - pIdle Proc (or how to let users know what’s going on during print time…) (÷1 ) of 3 (Ï ZM.PR.pIdleProc ˇ ° ¿Ù%%DSIDICT:_cv
currentdict /bu known {bu}if
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øà ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ' 2b *!B PrintingStatusDialog = GetNewDialog(257, nil, (WindowPtr) -1); ° d ONLN d C 1 <S *
? (**thePrRecHdl).prJob.pIdleProc = checkMyPrintDialogButton; ° d ONLN d É E P
*1 thePrPort = PrOpenDoc(thePrRecHdl, nil, nil); ° d ONLN d µ Y d , * ° d ONLN d π Y , d 8 )<< ° d ONLN d ª Y 8 då ) D more print loop would follow below, see Tech Note #161 for details ° d ONLN d ˇ Yå dò ( Ä™>>
° d ONLN d o { ( ó 64For a complete printing loop that handles errors at ° d ONLN d6 o {⁄ )Ó.print time and makes all of the right calls to ° d ONLN de { áê ( £ 6Nthe Printing Manager, refer to Technical Note #161, A Print Loop That Cares...
° d ONLN d¥ ü ÆJ *')Things To Remember About pIdle Procedures
° d ONLN dfi ∫ Δ " *It ° d ONLN d· ∫ " Δ⁄ )
Zis extremely important to design and code your pIdle procedure as defensively as possible, ° d ONLN d= Δ “ó ( Ó 6Rthereby making sure that it works with as many printer drivers as possible. This ° d ONLN dè Δó “⁄ ( Óµsection details ° d ONLN dü “ fi+ ( ˙ 68a few things to remember when creating pIdle procedures. ° d ONLN dÿ Í ˆ ˘ *%Saving And Restoring The Current Port ° d ONLN d˛ í *It is extremely important ° d ONLN d í )z to save the printer driver’s ° d ONLN d5Z )â GrafPort, ° d ONLN d>Z⁄ )? upon entry to your pIdle ° d ONLN dX ö (7 6Sprocedure and restore it upon exit. Why? If you do not, the printer driver would ° d ONLN d´ö⁄ (7∏
draw into the ° d ONLN dπ ' P (D 6GrafPort ° d ONLN d¡ P( Ò )8$ of your dialog box instead of it's ° d ONLN d Ò'0 )° GrafPort, ° d ONLN dÓ 0(⁄ )?"which will cause some bad results. ° d ONLN d) 5 | (Q 6To save the printer’s ° d ONLN d(( |4 ¥ )dGrafPort ° d ONLN d0) ¥5 ª )8, ° d ONLN d2) ª5 )you should call ° d ONLN dB( 4A )N_GetPort ° d ONLN dJ)A5⁄ )8 when entering your procedure. ° d ONLN dj6 B (^ 6/Before you exit your procedure, you would call ° d ONLN dô5A< )Ï_SetPort ° d ONLN d°6<B¢ )8 to set the port from ° d ONLN d∑6¢B⁄ )f your dialog ° d ONLN d√C O ≠ (k 6!box back to the printer driver’s ° d ONLN d‰B ≠N  )ïGrafPort ° d ONLN dÏC ÂOs )8 (i.e., the one you saved with ° d ONLN d BsN´ )é_GetPort ° d ONLN dC´O≥ )8). ° d ONLN d[ gJ (É 63Saving And Restoring The Printer Driver’s Resources ° d ONLN dJs *5If the application changes the resource chain within ° d ONLN ds ⁄ )Ù*it's pIdle procedure, you want to save and ° d ONLN d™ ã (ß 64restore the printer driver’s resource chain. Why? ° d ONLN dfiã⁄ (ß6&Some printer drivers assume that their ° d ONLN dã ó ˇ (≥ 6-resource chain does not change, but this may ° d ONLN d2ã ˇó⁄ )Á+not be true when the driver calls the pIdle ° d ONLN d^ó £ Û (ø 6*procedure installed by the application at ° d ONLN dàó Û£⁄ )€*print time. To accomplish this task, call ° d ONLN d≥£ Ø e (à 6 _CurResFile ° d ONLN dæ§ e∞ “ )M, saving the ID of the ° d ONLN d’§ “∞⁄ )m7printer driver’s resource file at the beginning of your ° d ONLN d
JO [ ÿ (w 6)within your idle procedure, and an error ° d ONLN d
sO ÿ[⁄ )¿6occurs, never abort printing within the idle procedure ° d ONLN d
™[ gö (É 6Uitself. Wait until the last called printing procedure returns, then check to see if ° d ONLN d
ˇ[ög⁄ (É∏the error still ° d ONLN d g s— (è 6`remains. Attempting to abort printing within an idle procedure is a guarantee of certain death. ¡ 4¡˘
*G2 ) of 3 )pPPR 22 - pIdle Proc (or how to let users know what’s going on during print time…) (Ï∑M.PR.pIdleProc ˇé ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +Z-Developer Support Center ( -
April 1991 / X /
° d ONLN d ) < 52 ( Q Z)Canceling Or Pausing The Printing Process ° d ONLN d * A < M µ *If you install a procedure ° d ONLN d E A µ M˛ )yEfor handling requests to cancel printing, with an option to pause the ° d ONLN d ã M < Y@ ( u Z-printing process, beware of timeout problems ° d ONLN d ∏ M@ Y˛ ( u^!when printing to the LaserWriter. ° d ONLN d € Y < e{ ( Å Z=Communication between the Macintosh and the LaserWriter must ° d ONLN d Y{ e˛ ( Åôbe maintained to prevent a ° d ONLN d3 e < q` ( ç Z:job or a wait timeout. If there is not any communication ° d ONLN dm e` q˛ ( ç~ for a period of time (over two ° d ONLN då q < }‰ ( ô ZZminutes), the printer times out and the print job terminates due to a wait timeout. Or, ° d ONLN dÊ q‰ }˛ ( ôif the ° d ONLN dÌ } < ⃠( • ZWprint job requires more than three minutes to print, the print job terminates due to a ° d ONLN dD }ƒ Ⲡ( •‚ job timeout. ° d ONLN dR â < ï’ ( ± ZYSince, there is not a good method to determine to what type of printer an application is ° d ONLN d´ â’ ï˛ ( ±Û printing, ° d ONLN dµ ï < °Y ( Ω Z<it is probably a good idea to document the possibility of a ° d ONLN dÒ ïY °˛ ( Ωw!LaserWriter timing out for a user ° d ONLN d ° < ≠5 ( … Z3who chooses to select “pause” for over two minutes. ° d ONLN dG π < ≈v *4Some Printer Drivers Do Not Support pIdle Procedures ° d ONLN d| — < › ∑ *Some printer drivers do ° d ONLN dî — ∑ ›˛ ){@not support pIdle procedures, as they prefer to handle the pIdle ° d ONLN d’ › < Èe ( Z>procedure in their own manner without giving an application’s ° d ONLN d ›e È˛ (É pIdle procedure any time. This ° d ONLN d3 È < ı¬ ( ZOsituation should not be a problem as long as you do not assume that your pIdle ° d ONLN dÇ È¬ ı˛ (‡ procedure is ° d ONLN dè ı <
( Z-always called at print time. Therefore, you ° d ONLN dº ı
˛ )Œ2should only create your pIdle procedure to display ° d ONLN dÔ <
ø () ZSthe dialog box and respond to a user pausing, continuing, or canceling a print job.
° d ONLN dC% <4 Ö *'
Conclusion
° d ONLN dN@ <Lq *AWhen installing your pIdle proc, it must be installed before the ° d ONLN dè@qL˛ (hè application calls PrOpenDoc. ° d ONLN d≠L <X√ (t ZNYou want to make sure that you save and restore the GrafPort , upon entry and ° d ONLN d˚L√X˛ (t· exit of your ° d ONLN dX <d Ò (Ä Z'pIdle procedure, to make sure that the ° d ONLN d/X Òd˛ )µ:printer driver will image into the correct port during the ° d ONLN djd <p € (å Z print job. Finally, if you are ° d ONLN däd €p˛ )ü6changing the resource chain by calling _OpenResFile or ° d ONLN d¡p <|¿ (ò ZP_UseResFIle, you want to make sure that you save and restore the resource chain. ° d ONLN d† <¨ ¶ *0Further Reference: À XÀ ° d ONLN d&≠ Nπ R +
• ° d ONLN d(≠ `π ± )Inside Macintosh ° d ONLN d8≠ ±πV )Q!, Volume II, The Printing Manager ° d ONLN dZπ N≈ R (· l• ° d ONLN d\π `≈ ) Technical Note M.IM.PrintLoop — ° d ONLN d~≈ Ñ— +$ A Print Loop That Cares... ¡ X¡
(÷ ZPPR 22 - pIdle Proc (or how to let users know what’s going on during print time…) (÷3 ) of 3 (Ï ZM.PR.pIdleProc ˇ" ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åâ ( õ Z'PR 23 - Position-Independent PostScript
° d ONLN d ( Ä < è s *Printing
° d ONLN d 2 õ < ß t * Revised by: ° d ONLN d ? õ≈ ߲ ( √„
March 1988 ° d ONLN d J ß < ≥ q ( œ Z Written by: ° d ONLN d V ß Ñ ≥ Û )HScott "ZZ" Zimmerman ° d ONLN d k ø < À ( Á Z+This technical note describes a method for ° d ONLN d ñ ø À˛ )fi.inserting position-independent PostScript into ° d ONLN d ≈ À < ◊ û ( Û ZQuickDraw pictures. X ° d ONLN d Ÿ < ¸ e *% There is ° d ONLN d ‚ e ¸˛ ))Sa problem with pictures that contain PostScript code. Sometimes the PostScript code ° d ONLN d6 ¸ < fi ($ Z%that is inserted into the picture is ° d ONLN d[ ¸ fi˛ )¢9dependent on the position of the picture on the page. The ° d ONLN dï <r (0 Z@problem arises when these pictures are cut or copied from their ° d ONLN d’r˛ (0ê original position, and pasted ° d ONLN dÛ < T (< Z9into another position or even into another document. The ° d ONLN d,T ˛ (<r!PostScript code will not know the ° d ONLN dN <,N (H Z<new location of the picture, and will not execute correctly. ° d ONLN dã8 <D> *6The solution for this problem, is to provide some way ° d ONLN d¡8>D˛ (`\(for the PostScript code to determine the ° d ONLN dÍD <PØ (l ZRcurrent location of the picture relative to the page that it is being printed on. ° d ONLN d<DØP˛ (lÕThis is done by ° d ONLN dLP <\ì (x ZCinserting QuickDraw calls to position the LaserWriter’s pen before ° d ONLN dèPì\˛ (x±inserting the position ° d ONLN d¶\ <h™ (Ñ ZKdependent PostScript code. When the PostScript in the picture is executed, ° d ONLN dÒ\™h˛ (Ñ»the LaserWriter’s ° d ONLN dh <tΩ (ê ZWpen location will be in a location relative to the position of the picture on the page. ° d ONLN d[Ä <åk *;The following example illustrates a method for positioning ° d ONLN dñÄkå˛ (®â the LaserWriter’s pen before ° d ONLN d≥å <òΔ (¥ ZSinserting any PostScript code into the picture. The method uses QuickDraw calls to ° d ONLN dåΔò˛ (¥‰ position the ° d ONLN dò <§ … (¿ Z LaserWriter’s pen, and will ° d ONLN d/ò …§˛ )ç;work with any application that supports QuickDraw pictures. ° d ONLN dk§ <∞£ (à ZJApplications do not have to be changed to be able to print pictures which ° d ONLN dµ§£∞˛ (áuse this technique; ° d ONLN d…± <Ω Ñ (Ÿ Znormal calls to ,
Courier ° d ONLN dŸ∞ Ѻ — )H DrawPicture ° d ONLN d‰± —Ω )M will work. ° d ONLN d <÷ Q (Ú ZThe ° d ONLN dÙ Q÷˛ )Zfollowing code fragment will create a picture that contains PostScript to draw a rectangle ° d ONLN dO÷ <‚ ª (˛ Zaround the picture’s frame:
° d ONLN dkÓ <˘E *5FUNCTION CreatePicture(pictureRect: Rect): PicHandle; ° d ONLN d£¯ ` ~ +$
CONST ° d ONLN dÆ Ñ
˜ +$
PostScriptBegin = 190; ° d ONLN d Ñ Ì *
PostScriptEnd = 191; ° d ONLN d‰ Ñ! ˜ *
PostScriptHandle = 192; ° d ONLN d˛ `+ t (G ~VAR ° d ONLN d* Ñ5 ± +$
PSString ° d ONLN d* Ã5 ˛ )H
: Str255; ° d ONLN d 4 Ñ? ± ([ ¢ PSHandle ° d ONLN d*4 Ã? ˛ )H
: Handle; ° d ONLN d9> ÑI ± (e ¢ theError ° d ONLN dC> ÃI Ù )H: OSErr; ° d ONLN dNH `S ~ (o ~BEGIN ° d ONLN dYR Ñ] +$
(* Create a new Picture. *) ° d ONLN dz\ Ñg[ *
+CreatePicture := OpenPicture(pictureRect); ° d ONLN d¨f ®q +$
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø¬ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ` (å +H<(* Set the pen size to 0,0 so the following Line will not *) ° d ONLN d = ' 2 ( N 6 ° d ONLN d @ ' ` 2d )H4(* be shown, it is only sent to position the pen.*) ° d ONLN d z 1 Ñ < ≈ +$
PenSize(0,0); ° d ONLN d ã E ` PÇ ( l ~:(* Move the QuickDraw pen to the first pixel inside the *) ° d ONLN d » O ` Z_ *
3(* the picture’s frame. This by itself will not *) ° d ONLN d ˛ Y ` dA *
-(* change the LaserWriter’s pen location! *) ° d ONLN d/ c ` n2 *
*MoveTo(pictureRect.left, pictureRect.top); ° d ONLN d^ w ` Ç} *9(* Force the LaserWriter’s pen location to match the *) ° d ONLN dú Å Ñ åµ +$
7(* the Line procedure only causes the coordinates of *) ° d ONLN dê ≥ æ ( ⁄ 6 ° d ONLN dì ≥ ` æ} )H9(* the above MoveTo to be flushed to the LaserWriter. *) ° d ONLN d— Ω Ñ »¶ +$
:(* Because of the PenSize call above, no Line is drawn. *) ° d ONLN d « “ ( Ó 6 ° d ONLN d « ` “ í )H
Line(0,0); ° d ONLN d € ` Ê- *)(* Reset the pen to its default size. *) ° d ONLN dK Â ` ° *
PenSize(1,1); ° d ONLN d\ ˘ `† *@(* The LaserWriter’s pen location has now been changed. The *) ° d ONLN d† Ѷ +$
:(* PostScript currentpoint operator will now return the *) ° d ONLN d€
(4 6 ° d ONLN dfi
`Z )H2(* location of the center pixel of the Picture. *) ° d ONLN d `"7 *
+(* Get the PostScript ready to be sent. *) ° d ONLN dE! `, ´ *
(* currentpoint ° d ONLN dV! ,Ã )ê,- push the current Point onto the stack. *) ° d ONLN dÖ+ Ñ6 ∂ (R ¢
(* newpath ° d ONLN dí+6™ )ê - Begin a new Line segment. *) ° d ONLN d±5 @ (\ 6 ° d ONLN d¥5 `@ ç )H (* MoveTo ° d ONLN d¿5 @÷ )ê.- Move to the currentpoint we saved above. *) ° d ONLN dÒ? ÑJ ‘ (f ¢(* nn nn rlineto ° d ONLN d?Jæ )ê"- frame the Picture with lines. *) ° d ONLN d&I T (p 6 ° d ONLN d)I `T ç )H (* stroke ° d ONLN d3I ®T ≠ )H ° d ONLN d6I TT )H- Draw the frame. *) ° d ONLN dKS ^ (z 6 ° d ONLN dNS `^ ó )H PSString := ° d ONLN d]] `hØ *
; ° d ONLN dßq | (ò 6 ° d ONLN d™q `|ñ )H>PSString[length(PSString)] := CHR(13); (* Don’t forget CR. *) ° d ONLN dÌ{ ÑÜ[ +$
+theError:=PtrToHand(Ptr(ORD4(@PSString)+1), ° d ONLN d Ö Ãê] +H
PSHandle,length(PSString)); ° d ONLN d=è ö (∂ 6 ° d ONLN d@è `ö )H&IF theError <> noErr THEN HandleError; ° d ONLN dj£ `Æ_ *3(* Send the PostScript code to the LaserWriter. *) ° d ONLN d†≠ <∏ Ê (‘ Z"PicComment(PostScriptBegin,0,nil); ° d ONLN dΔ¡ ÑÃí +H6(* QuickDraw calls made between the PostScriptBegin *) ° d ONLN d À Ñ÷í *
6(* and PostScriptEnd PicComments will be ignored by *) ° d ONLN d:’ чB *
&(* devices that support PostScript. *) ° d ONLN ddÈ ÑÙ∫ *>PicComment(PostScriptHandle,GetHandleSize(PSHandle),PSHandle); ° d ONLN d¶˝ ` ($ ~ PicComment(PostScriptEnd,0,nil); ° d ONLN dÀ ` á *;(* Kill off the Handle we created and close the picture. *) ° d ONLN d & (B 6 ° d ONLN d
`& ” )HDisposHandle(PSHandle); ° d ONLN d%% `0 ¶ *
ClosePicture; ° d ONLN d6/ <: ¥ (V ZEND; (* CreatePicture *)
° d ONLN dOE Q ⁄ (m 6%See the LaserWriter Reference Manual ° d ONLN dtE ⁄Q⁄ )¬/for more information about PicComments. See the ° d ONLN d§R ^ € (z 6$PostScript Language Reference Manual ° d ONLN d»R €^P )√ for more information ° d ONLN dfiRP^Ü )u
about the ° d ONLN dËQÜ]⁄ )6 currentpoint ° d ONLN dı^ j C (Ü 6 operator. ¡ 4¡˘
° d ONLN d < ) ê ( E ZThere are some ° d ONLN d ê )˛ )TFimportant guidelines to follow when sending PostScript directly to the ° d ONLN d V ) < 5µ ( Q ZHLaserWriter. See the PostScript Commands section of Technical Note #91, ° d ONLN d û )µ 5˛ ( Q”for a complete ° d ONLN d ≠ 5 < A œ ( ] Z description of these guidelines. ° d ONLN d Œ e < q ¶ *0Further Reference: ê X ê ° d ONLN d · r N ~ R +
• ° d ONLN d „ r ` ~ ∏ )The Print Manager ° d ONLN d ı ~ N ä R ( ¶ l• ° d ONLN d ˜ ~ ` ä ñ ) QuickDraw ° d ONLN d ä N ñ R ( ≤ l• ° d ONLN d ä ` ñ ) LaserWriter Reference Manual ° d ONLN d ñ N ¢ R ( æ l• ° d ONLN d" ñ ` ¢ )"Technical Note M.IM.PictComments — ° d ONLN dG ¢ Ñ Æo +$ , Optimizing for the LaserWriter—PicComments ° d ONLN dt Æ N ∫ R ( ÷ l• ° d ONLN dv Æ ` ∫ )$PostScript Language Reference Manual ° d ONLN dö Æ ∫k )∫, Adobe Systems ° d ONLN d™ ∫ N Δ R ( ‚ l• ° d ONLN d¨ ∫ ` Δ3 ))PostScript Language Cookbook and Tutorial ° d ONLN d’ ∫3 ΔÑ )”, Adobe Systems ¡ X¡
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å ( õ ZPR 505 - PostScript Q&As
° d ONLN d Ä < è s *Printing
° d ONLN d # õ < ß t * Revised by: ° d ONLN d / õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d H õ± ߲ ( √œSeptember 1993 ° d ONLN d W ß < ≥ q ( œ Z Written by: ° d ONLN d c ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d | ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d â ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ® ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d ‚ À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d) À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN d< ◊ < „ u ( ˇ Z
While DSC ° d ONLN dF ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dì „ < Ô q ( Z don’t have ° d ONLN dû „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN d Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dE ˚ < (# Z,information migrates into reference manuals. ° d ONLN dr < k *:Q&As are now included with Technical Notes to make access ° d ONLN d¨k ˛ (;â to technical updates easier for ° d ONLN dà <+. (G Z/you. If you have comments or suggestions about ° d ONLN d˚ .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d&+ <7 \ (S Zknow ° d ONLN d++ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN du7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. n Xn
° d ONLN dØh <w  *4PostScript documentation
° d ONLN d»w <É § * Date Written: 7/13/90 ° d ONLN dflÉ <è • * Last reviewed: 8/1/92 ° d ONLN dˆõ <ß *,Adobe Systems publishes three great manuals ° d ONLN d"õ ߲ )·+that can help you with PostScript commands: ° d ONLN dNß <≥J (œ Z1PostScript Language Reference Manual, PostScript ° d ONLN dßJ≥™ (œhLanguage Tutorial, ° d ONLN dëß™≥Õ )` and ° d ONLN dñßÕ≥˛ )#
PostScript ° d ONLN d°≥ <ø n (€ Z Language ° d ONLN d™≥ nø § )2 Cookbook. ° d ONLN d≥≥ §ø˛ )6C You can find these manuals at just about any bookstore, or you can ° d ONLN d˜ø <Àí (Á ZEorder them through APDA by calling (800) 282-2732 or writing them at: ° d ONLN d=◊ <„ § *Apple Computer, Inc. ° d ONLN dR„ <Ô ˘ * $20525 Mariani Avenue, Mail Stop 33-G ° d ONLN dwÔ <˚ £ * Cupertino, CA 95014
° d ONLN dã <"† *'1AppleTalk packets and PostScriptHandle PicComment
° d ONLN dΩ" <. û * Date Written: 8/7/90 ° d ONLN d”. <: • * Last reviewed: 8/1/92 ° d ONLN dÍF <R õ *What’s the optimal ° d ONLN d˝F õR˛ )_Camount of PostScript to pass in PicComment 192 for AppleTalk packet ° d ONLN dAR <^ u (z Z throughput? ° d ONLN dM^ <j N * ___ ° d ONLN dQv <Ç *'There is no one optimal size that your ° d ONLN dxv Dz )¥3PostScriptHandle PicComment should be for AppleTalk ° d ONLN d¨Ç <é (™ Z
packets. The ° d ONLN dπÇ é˛ )CJLaserWriter driver sends different amounts of PostScript, depending on the ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø: ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )p *Hamount of memory that is available. It could send as little as 1K or as ° d ONLN d H p )⁄ ( Eémuch as 4K bytes of ° d ONLN d \ ) 5 ( Q 61PostScript at one time. The driver is using four ° d ONLN d ç ) 5⁄ )Í+4096-byte buffers to send the data, and the ° d ONLN d π 5 AΩ ( ] 6Vamount of data that it sends from a particular buffer is completely memory dependent. ° d ONLN d 5Ω A⁄ ( ]€In the ° d ONLN d A M ~ ( i 6general case, it does ° d ONLN d, A ~ M⁄ )fHnot send any data until a particular buffer is full. The driver does not ° d ONLN du M Yì ( u 6Ncontrol the number of packets that are sent over AppleTalk. When PAP receives ° d ONLN d√ Mì Y⁄ ( u±the PostScript, ° d ONLN d” Y e ( Å 60it packages up the PostScript and sends it down ° d ONLN d Y e⁄ )ˇ$to the LaserWriter. In general, DTS ° d ONLN d( e q∂ ( ç 6Wrecommends that applications send a PostScript handle that contains 4096 bytes of data.
° d ONLN dÄ â òj *'2Using PostScript to control LaserWriter serial I/O
° d ONLN d≥ ò § Ä * Date Written: 12/6/90 ° d ONLN d § ∞ á * Last reviewed: 3/28/93 ° d ONLN d‚ º » r *Where can I find ° d ONLN dÛ º r »⁄ )ZGinformation on using PostScript to control a multi-tray sheet feeder by ° d ONLN d; » ‘ ( 62communicating through the LaserWriter serial port? ° d ONLN dn ‘ ‡ * * ___ ° d ONLN dr Ï ¯ È *(You need to talk with Adobe on how they ° d ONLN dö Ï È ¯⁄ )—1control the serial chip with PostScript. They use ° d ONLN dà ¯ ( 62some undocumented PostScript calls to control the ° d ONLN d˛ ¯⁄ )¯*serial chip on the controller board of the ° d ONLN d) ≈ (, 6$LaserWriter. They can be reached at: ° d ONLN dN ( ã * Adobe Systems, Inc. ° d ONLN dg( 4 ë * 1585 Charleston Road ° d ONLN dÅ4 @ Æ * Mountain View, CA 94039 ° d ONLN d†L X " *or ° d ONLN d£d p *2 AppleLink Address: ADOBE.SUPT (Tech Support) ° d ONLN d÷| à X *Details about ° d ONLN d‰| Xà⁄ )@Qinstalling feeder resources for Macintosh into the LaserWriter driver 7.0 dialogs ° d ONLN d6à îC (∞ 6>are available in the Macintosh Technical Note “Feeder Fodder.”
° d ONLN du¨ ª *'$How to inhibit LaserWriter test page
° d ONLN döª « Ü * Date Written: 12/24/90 ° d ONLN d≤« ” Å * Last reviewed: 8/1/92 ° d ONLN d…fl Î ˚ *0How do I inhibit the test page on a LaserWriter? ° d ONLN d˙Î ˜ * * ___ ° d ONLN d˛ T *F1. Use the LaserWriter Utility to turn the startup page off (best), or ° d ONLN dE ' *.2. Download the following PostScript commands: ,
° d ONLN dºg sΔ *UThe above commands can be downloaded from your Macintosh to the printer several ways: ° d ONLN d ã∫ *V1. Use the menu command in the LaserWriter Utility that comes with System 7 (easiest). ° d ONLN diã óå * N2. You can use a PostScript utility like LaserTalk from Emerald City Software. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < )B ( E Z63. The PostScript Language facility in Microsoft Word. ° d ONLN d 7 ) < 5 ® * 4. PSDump or PSsend ° d ONLN d K 5 < A± * R5. Use the PostScript utilities in the Developer CD’s PostScript Utilities folder. ° d ONLN d û A < M| * A6. Use the methods described in the Macintosh Technical Note #91. ° d ONLN d ‡ Y < e r * When you ° d ONLN d È Y r e˛ )6Lissue the commands, your LaserWriter will probably crank and grind for a few ° d ONLN d6 e < q~ ( ç Z?seconds (it has to re-program the EPROM inside) then after the ° d ONLN du e~ q˛ ( çúlights stop flashing, your ° d ONLN dê q < } ¿ ( ô ZLaserWriter will no longer ° d ONLN d´ q ¿ }˛ )ÑBspit out the startup page until you enable the setdostartpage flag ° d ONLN dÓ } < â9 ( • Z6again (in other words, this isn’t a permanent change). ° d ONLN d% ï < ° ‰ *"For more information on the above ° d ONLN dG ï ‰ °h )®subject we recommend the ° d ONLN d` ïh °˛ )Ñ PostScript Language Reference ° d ONLN d~ ° < ≠ _ ( … ZManual ° d ONLN dÑ ° _ ≠ ø )# by Adobe Systems.
° d ONLN dó ≈ < ‘Û ( Z?Where to find Encapsulated PostScript file (EPSF) documentation
° d ONLN d◊ ‘ < ‡ û * Date Written: 4/5/91 ° d ONLN dÌ ‡ < Ï • * Last reviewed: 8/1/92 ° d ONLN d ¯ < P *I’m ° d ONLN d ¯ P˛ )Xdeveloping an application that creates pictures containing both QuickDraw and PostScript ° d ONLN da <À (, ZM(as picComments). How do I create an encapsulated PostScript file (EPSF)? Is ° d ONLN dÆÀ˛ (,È
the format ° d ONLN dπ < % (8 Z2explained anywhere, and is it possible to convert ° d ONLN dÎ% ˛ )È-the QuickDraw into PostScript directly in the ° d ONLN d <( t (D Z application? ° d ONLN d&( <4 N * ___ ° d ONLN d*@ <Lõ *FAdobe’s EPSF format is documented in the new (2nd) edition of Adobe’s ° d ONLN dp@õL˛ (hπPostScript Language ° d ONLN dÑL <X î (t ZReference Manual ° d ONLN dîL îX} )X) (Addison-Wesley) and in “Adobe Document ° d ONLN dΩL}X˛ )ÈStructuring Conventions,” ° d ONLN d◊X <dı (Ä ZYavailable from Adobe Systems. Adobe’s references explain how to structure your comments ° d ONLN d0Xıd˛ (Äin ° d ONLN d3d <pv (å ZDyour PostScript file so that other applications know how to read it. ° d ONLN dx| <à$ **You probably don’t want to try to convert ° d ONLN d¢|$à˛ )Ë(QuickDraw to PostScript directly in your ° d ONLN dÀà <îñ (∞ ZNapplication, although it is possible. Basically, it involves translating each ° d ONLN dàñî˛ (∞¥QuickDraw command ° d ONLN d+î <† ¥ (º Zinto PostScript, which is ° d ONLN dEî ¥†˛ )xBwhat the LaserWriter Driver does. It’s a lot of work and makes you ° d ONLN dà† <¨
(» Z*dependent on the QuickDraw features being ° d ONLN d≤†
¨˛ )—.used, which can be a problem when new features ° d ONLN d·¨ <∏ m (‘ Z
are added.
° d ONLN dÏ– <fl∑ *'9PostScript setprintername doesn’t accept colons in string
° d ONLN d&fl <Î § * Date Written: 4/16/91 ° d ONLN d=Î <˜ • * Last reviewed: 8/1/92 ° d ONLN dT <¬ *MWhy can’t I use a colon with the PostScript command setprintername to change ° d ONLN d°¬˛ (+‡ the Personal ° d ONLN dÆ <¨ (7 ZKLaserWriter NT network name and type, but it works with the LaserWriter II? ° d ONLN d˙ <' N * ___ ° d ONLN d˛3 <? ƒ * The reason that the Personal ° d ONLN d3 ƒ?˛ )à@LaserWriter NT is not accepting the PostScript you’re sending is ° d ONLN d\? <K ‰ (g Z#not because of a bug, but rather a ° d ONLN d? ‰K˛ )®8bug fix. Colons have never been acceptable in the string ° d ONLN d∏K <W œ (s Z passed to setprintername. (See ° d ONLN d◊K œW9 )ìpage 296 of Adobe’s ° d ONLN dÎK9W˛ )j&PostScript Language Reference Manual.) ° d ONLN d W <cª ( ZQThe reason the call works in older LaserWriters but not the Personal LaserWriter ° d ONLN d cWªc˛ (ŸNT is that the ° d ONLN d rc <o Q (ã ZNT ° d ONLN d uc Qo˛ )Thas a newer version of PostScript in it. Older versions of PostScript didn’t enforce ° d ONLN d o <{ı (ó ZWAdobe’s printer naming conventions. The setprintername restrictions have been enforced ° d ONLN d
!oı{˛ (óin ° d ONLN d
${ <áx (£ ZAmore recent versions, however. Therefore, colons are not allowed. ¡ X¡
° d ONLN d )H *>If you need to change the LaserWriter network type, it can be ° d ONLN d > H )⁄ ( Ef done with the AppleTalk-type ° d ONLN d [ ) 5 à ( Q 6parameter described on ° d ONLN d r ) à 5 Ô )ppage 105 of Apple’s ° d ONLN d Ü ) Ô 5Z )gLaserWriter Reference ° d ONLN d õ )Z 5⁄ )k manual. This method will ° d ONLN d µ 5 A Á ( ] 6,work on the new printers as well as the old.
° d ONLN d ‚ Y h3 *'(PostScript code for renaming LaserWriter
° d ONLN d h t z * Date Written: 6/5/91 ° d ONLN d! t Ä Å * Last reviewed: 8/1/92 ° d ONLN d8 å ò ˇ *-In checking a printer name to ensure an even ° d ONLN de å ˇ ò⁄ )Á*number of characters, does the LaserWriter ° d ONLN dê ò §
( ¿ 64Namer append a space to the end if the total is odd? ° d ONLN d≈ § ∞ * * ___ ° d ONLN d… º » „ **In a nutshell, yes. The Namer does indeed ° d ONLN dÛ º „ »⁄ )À2append an extra space to odd-length printer names. ° d ONLN d& » ‘ • ( 6 The reasoning behind this is ° d ONLN dC » • ‘⁄ )ç;to be compatible with some of the old 68000 processors. The ° d ONLN d ‘ ‡ ® ( ¸ 6addressing scheme of these ° d ONLN dö ‘ ® ‡÷ )ê7old processors requires that memory be accessed by even ° d ONLN d— ‘÷ ‡⁄ ( ¸Ù- ° d ONLN d“ ‡ Ï= ( 68numbered addresses. To get at a piece of memory located ° d ONLN d
‡= Ï⁄ ([ after an odd-length LaserWriter ° d ONLN d* Ï ¯ n ( 6name, you would ° d ONLN d: Ï n ¯⁄ )VJneed to get an odd-numbered address (which is not directly possible). This ° d ONLN dÖ ¯ ƒ ( 6 obviously can be worked around, ° d ONLN d• ¯ ƒ⁄ )¨7but the authors of the Namer felt it best to avoid this ° d ONLN d› Æ (, 6 altogether by padding the name ° d ONLN d¸ Æ⁄ )ñ<when necessary. It’s worth noting that the version 7.0 Namer ° d ONLN d9 X (8 6does this too. ° d ONLN dH( 4´ *WIf you’d like to work around this, here’s an alternate method for renaming the printer: ° d ONLN d†@ L z *The printer name is ° d ONLN d¥@ zL⁄ )bIstored as a string in the persistent parameters of all LaserWriters. This ° d ONLN d˛L X1 (t 6:string can be changed by the following PostScript program: ,
Courier
° d ONLN d9d o Ω *! serverdict begin 0 exitserver ° d ONLN d[n y ˘ *
- statusdict begin (NEWNAME) setprintername
° d ONLN dâÑ êg *<Replace NEWNAME with the name you want for the printer. The ° d ONLN d≈Ñgê⁄ (¨Öname can be up to 31 ° d ONLN d⁄ê ú J (∏ 6 characters ° d ONLN dÂê Jú⁄ )2Sand should consist entirely of printing characters--the “@” and “:” cannot be used. ° d ONLN d9ú ® º (ƒ 6#Note that parentheses are required. ° d ONLN d]¥ ¿F *>This program can be downloaded to the LaserWriter in batch or ° d ONLN dõ¥F¿⁄ (‹d interactive mode. In interactive ° d ONLN dº¿ Ã Ñ (Ë 6mode you should type ° d ONLN d—¿ ÑÃ⁄ )lDboth command strings on the same line before pressing Enter, because ° d ONLN dà ÿ Õ (Ù 6$exitserver disconnects you from the ° d ONLN d:à Õÿ⁄ )µ4printer. When you reestablish your connection to the ° d ONLN doÿ ‰ π ( 6"printer, the name will be changed. ° d ONLN dí ¸ › *(Make sure you have selected the correct ° d ONLN d∫ ›¸⁄ )≈0LaserWriter using the Chooser before downloading ° d ONLN dθ . ($ 68this program, so you don’t rename the wrong LaserWriter.
° d ONLN d$ /ë *'7Printing 2-byte bitmap fonts on PostScript LaserWriters
° d ONLN d\/ ; Ä * Date Written: 9/29/91 ° d ONLN ds; G Å * Last reviewed: 8/1/92 ° d ONLN däS _ Ò *+The Macintosh Technical Note #91 refers to ° d ONLN dµS Ò_⁄ )Ÿ,using QuickDraw picComments to print rotated ° d ONLN d‚_ k 0 (á 6text, ° d ONLN dË_ 0k⁄ )Ubut this doesn’t work for 2-byte Japanese text. Is there a recommended workaround for ° d ONLN d >k w X (ì 6
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ) ß ( E ZTwo-byte characters ° d ONLN d ß )˛ )k=don’t print when using the TextBegin, TextCenter, and TextEnd ° d ONLN d R ) < 5≤ ( Q ZKPicComments because of the structure of the data that is being sent in the ° d ONLN d ù )≤ 5˛ ( Q–
comments. The ° d ONLN d ´ 5 < Ac ( ] Z>LaserWriter driver uses these PicComments to rotate text, and ° d ONLN d È 5c A˛ ( ]Å"it is not expecting the data to be ° d ONLN d A < Mà ( i ZGin the 2-byte format. The 2-byte format is converted to bitmap data by ° d ONLN dS Aà M˛ ( i¶the driver, so the data is ° d ONLN dn M < Y¯ ( u Z^ignored and nothing is printed. The driver is expecting the comments to contain “normal” text. ° d ONLN dÕ e < q Ä *Since the data ° d ONLN d‹ e Ä q˛ )DJis in bitmap format, you can use the RotateBegin and RotateEnd PicComments ° d ONLN d' q < } · ( ô Z$to perform the rotation, as follows: ,
Courier
° d ONLN dL â < î s * RotateBegin ° d ONLN dX ì < ûã *
C DrawString (...); << To rotate your 2 byte Japanese characters ° d ONLN dú ù < ® i *
RotateEnd
° d ONLN d¶ ≥ < ø Í *(The tricky part of the solution is that ° d ONLN dŒ ≥ Í ø˛ )Æ7you only need to use this approach when you’re printing ° d ONLN d ø < À& ( Á Z02-byte Japanese bitmap fonts. Therefore, you’ll ° d ONLN d6 ø& À˛ )Í,need to check the type of data that is to be ° d ONLN dc À < ◊ ( Û Z.printed, and send the appropriate PicComments. ° d ONLN dí „ < Ô‡ *PYou can also use the following PicComments to hide the QuickDraw representation ° d ONLN d‚ „‡ Ô˛ ( ˛of the ° d ONLN dÈ Ô < ˚ « ( Z rotated text, as shown below:
° d ONLN d < á *PostScriptBegin ° d ONLN d < ; *
3 CopyBits (...); << For the QuickDraw printers ° d ONLN dK <& } *
PostScriptEnd
° d ONLN dY1 <=Á *VThe PostScriptBegin and PostScriptEnd PicComments are used to hide the CopyBits calls ° d ONLN dØ1Á=˛ (Yfrom ° d ONLN d¥= <I ∑ (e Zthe LaserWriter driver in ° d ONLN dŒ= ∑I˛ ){>a device-independent manner. When you use PostScriptBegin, the ° d ONLN d
I <U• (q ZHLaserWriter driver doesn’t interpret any QuickDraw calls until it finds ° d ONLN dUI•U˛ (q√the PostScriptEnd ° d ONLN dgU <a7 (} Z/PicComment. Since QuickDraw printer drivers do ° d ONLN dñU7aF )˚not ° d ONLN dôUFa˛ )# understand the PostScriptBegin and ° d ONLN dΩa <m É (â ZPostScriptEnd ° d ONLN dÀa Ém˛ )GJPicComments, they ignore the PicComments, and the CopyBits call is used to ° d ONLN dm <y ÿ (ï Z"perform the rotation of your text. ° d ONLN d9Ö <ë ≈ *There is one problem with ° d ONLN dSÖ ≈ë˛ )â=the previously mentioned solution: If you record the previous ° d ONLN dëë <ùà (π ZTPicComments into a picture and print it, everything will print exactly as expected, ° d ONLN dÂëÃù˛ (πÍ
° d ONLN dÊ! <0É *'/Macintosh spooling should be device independent
° d ONLN d 0 << û * Date Written: 1/1/90 ° d ONLN d ,< <H • * Last reviewed: 8/1/92 ° d ONLN d CT <`É *EHow can I tell whether the chosen printer supports PostScript or not? ° d ONLN d â` <l N * ___ ° d ONLN d çx <Ñt *<There is no supported method for determining whether or not ° d ONLN d …xtÑ˛ (†ía device speaks PostScript. ° d ONLN d ÂÑ <ê$ (¨ Z+Apple engineering would like all Macintosh ° d ONLN d
Ñ$ê˛ )Ë)applications to spool both PostScript and ¡ X¡
° d ONLN d ) *4QuickDraw regardless of the chosen printer, so that ° d ONLN d 4 )⁄ )˛(the spool file is device-independent and ° d ONLN d ] ) 5> ( Q 6@can be redirected after spooling. Since engineering is strongly ° d ONLN d ù )> 5⁄ ( Q\ encouraging developers to spool ° d ONLN d Ω 5 A ò ( ] 6 both models, it is doubtful ° d ONLN d Ÿ 5 ò A⁄ )ÄAthat Apple will be providing a query mechanism in the future. The ° d ONLN d A M w ( i 6best method is to ° d ONLN d- A w M⁄ )_Aassume PostScript is available, and format your document based on ° d ONLN do M Y ( u 67information returned by PrGeneral and the print record.
° d ONLN dß q ÄB *'*LaserWriter driver and PostScript showpage
° d ONLN d“ Ä å z * Date Written: 1/1/90 ° d ONLN dË å ò á * Last reviewed: 6/14/93 ° d ONLN d § ∞ü *SWhen I print a PostScript file, why do I get one blank page for every page printed? ° d ONLN dT ∞ º * * ___ ° d ONLN dX » ‘ö *RYour PostScript file probably contains calls to the PostScript showpage operator. ° d ONLN d™ »ö ‘⁄ ( ∏
This operator ° d ONLN d∏ ‘ ‡ 9 ( ¸ 6is also ° d ONLN d¿ ‘ 9 ‡⁄ )!Ucalled by the Macintosh LaserWriter driver when it receives the PrClosePage call. The ° d ONLN d ‡ Ïæ ( 6Zsolution to this problem is to strip showpage calls from the file before sending the file ° d ONLN dp ‡æ Ï⁄ (‹to the ° d ONLN dw Ï ¯ê ( 6MLaserWriter. If you send one QuickDraw graphic at the beginning of each page, ,
Courier
° d ONLN d≈ ü * MoveTo(-32000, -32000); ° d ONLN d· c *
Line(0, 0);
° d ONLN dÒ$ 0 Ë *+the LaserWriter driver will handle calling ° d ONLN d $ Ë0⁄ )–-showpage for you. Versions of the LaserWriter ° d ONLN dJ0 <u (X 6Gdriver before 5.2 do not send the showpage operator unless a QuickDraw ° d ONLN dë0u<⁄ (Xìdrawing routine (that ° d ONLN dß< H e (d 6is, something ° d ONLN dµ< eH⁄ )M>other than PicComment) is sent. This is why you need to do the ° d ONLN dÙH Tõ (p 6FMoveTo/LineTo. Versions 5.2 and later will send the showpage operator ° d ONLN d:HõT⁄ (pπ whether any ° d ONLN dFT `Ã (| 6VQuickDraw has been sent or not. Since you can’t be sure whether showpage will be sent ° d ONLN dúTÃ`⁄ (|Ífor ° d ONLN d†` lS (à 6Gyou or not, the best solution is to let the LaserWriter driver send it.
° d ONLN dËÑ ìÉ *'3PicComment TextIsPostScript versus PostScriptHandle
° d ONLN d ì ü z * Date Written: 1/1/90 ° d ONLN d2ü ´ á * Last reviewed: 6/14/93 ° d ONLN dJ∑ √ ° *When using the Macintosh ° d ONLN dc∑ °√⁄ )â<TextIsPostScript picture comment, my PostScript code is also ° d ONLN d†√ œ (Î 63“printed” on the ImageWriter. Why isn’t it ignored? ° d ONLN d‘œ € * * ___ ° d ONLN dÿÁ Û Ì *'One of the comments, TextIsPostScript, ° d ONLN dˇÁ ÌÛ⁄ )’+allows the application to use the QuickDraw ° d ONLN d+Û ˇT ( 6ADrawString procedure to send the PostScript code. This method is ° d ONLN dlÛTˇ⁄ (rno longer recommended, as ° d ONLN dܡ ø (' 6%it is not device independent. If you ° d ONLN d´ˇ ø ÷ )ß7use the TextIsPostScript comment when printing to a non ° d ONLN d‚ˇ÷ ⁄ ('Ù- ° d ONLN d„ , (3 6:PostScript device, the PostScript code will be printed as ° d ONLN d ,⁄ (3J#text. On an ImageWriter, the entire ° d ONLN dA # » (? 6#PostScript program will be printed ° d ONLN dd »#⁄ )∞5as one line on the page, because the TextIsPostScript ° d ONLN dö# /ù (K 6KPicComment is ignored by the ImageWriter drivers, and the DrawString calls ° d ONLN dÂ#ù/⁄ (Kª are executed ° d ONLN dÚ/ ; F (W 6 normally. ° d ONLN d¸G SØ *PTo avoid this problem, developers should use the PostScriptHandle comment. This ° d ONLN d LGØS⁄ (oÕcomment ° d ONLN d TS _ x ({ 6accepts a handle as ° d ONLN d hS x_⁄ )`Fa parameter. The handle points to the PostScript code that you want to ° d ONLN d Ø_ k (á 61download. This comment is better for two reasons: ° d ONLN d ·w É U *
First, there ° d ONLN d Ów UÉ⁄ )=Jis no QuickDraw/PostScript interaction. For example, early versions of the ° d ONLN d
9É è fl (´ 6+LaserWriter driver sent the strings passed ° d ONLN d
dÉ flè⁄ )«5to DrawString as-is. The latest version of the driver ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ) Œ ( E Z appends carriage returns onto ° d ONLN d Œ )˛ )í>those strings. If your application is expecting the DrawString ° d ONLN d ] ) < 5T ( Q Z;calls to work one way or another, you might get a surprise. ° d ONLN d ô A < M S *The ° d ONLN d ù A S M˛ )Qother reason for using the PostScriptHandle comment involves device independence. ° d ONLN d Ô M < Y ≠ ( u ZWhen a non-PostScript ° d ONLN d M ≠ Y˛ )qDdriver sees the PostScriptHandle PicComment, it not only ignores the ° d ONLN dJ Y < e ô ( Å Zcomment, but also ° d ONLN d\ Y ô e˛ )]Fignores the PostScript data that was passed to the comment, so nothing ° d ONLN d£ e < q¢ ( ç ZJprints if you use the PostScriptHandle comment on a non-PostScript driver. ° d ONLN dÓ } < â ] *X-Ref: ° d ONLN dı â < ï… * LMacintosh Technical Note “How To Produce Continuous Sound Without Clicking”
° d ONLN dB ≠ < ºfl *'<How to send PostScript from the Macintosh to the LaserWriter
° d ONLN d º < » û * Date Written: 5/3/89 ° d ONLN dï » < ‘ ´ * Last reviewed: 6/14/93 ° d ONLN d≠ ‡ < Ïs *?How do I send PostScript from the Macintosh to the LaserWriter? ° d ONLN dÌ Ï < ¯ N * ___ ° d ONLN dÒ <| *DThe best method for sending PostScript to the LaserWriter is to use ° d ONLN d5|˛ (,öthe PostScriptHandle (kind ° d ONLN dP < Á (8 Z = 192) PicComment documented ° d ONLN dm Á ˛ )´4in the Macintosh Technical Notes “Optimizing for the ° d ONLN d¢ <( (D Z'LaserWriter” and “Picture Comments—the ° d ONLN d… (˛ )’+Real Deal.” There are a few PicComments for ° d ONLN dı( <4 (P ZOsending PostScript to the LaserWriter, but the easiest to use and most problem ° d ONLN dD( 4˛ (PË free is the ° d ONLN dP4 <@ (\ Z'PostScriptHandle comment. One model is: ,
Courier
° d ONLN dxL <W å * PrOpenPage(...) ° d ONLN dâV <am *
= { Send some QuickDraw so that the Printing Manager gets a } ° d ONLN d«` <k6 *
2 { chance to define the clip region. } ° d ONLN d˙j <u ¥ *
MoveTo(-32000, -32000); ° d ONLN dt < x *
Line(0, 0); ° d ONLN d à <ì ı *% PicComment(PostScriptBegin, 0, NIL); ° d ONLN dFú <ß *) { QuickDraw representation of graphic. } ° d ONLN dp¶ <± ñ *
MoveTo(100, 100); ° d ONLN dÉ∞ <ª ñ *
LineTo(200, 200); ° d ONLN dñƒ <œ ** { PostScript representation of graphic. } ° d ONLN d¡Œ <ŸY *
E PicComment(PostScriptHandle,GetHandleSize(thePSHandle),thePSHandle); ° d ONLN dAÏ <˜ Î *# PicComment(PostScriptEnd, 0, NIL); ° d ONLN deˆ < ë *
PrClosePage(...)
° d ONLN dw < ¥ *The described fragment ° d ONLN dé ¥˛ )xBprints a line on any type of printer, PostScript or not. The first ° d ONLN d— <$ ˘ (@ Z$MoveTo/Line combination is required ° d ONLN dı ˘$˛ )Ω3to give the LaserWriter driver a chance to define a ° d ONLN d)$ <0 ⁄ (L Z!clipping region. The LaserWriter ° d ONLN dJ$ ⁄0˛ )û=driver replaces the grafProcs record in the GrafPort returned ° d ONLN dà0 <<° (X ZKfrom PrOpenDoc. In order for the LaserWriter driver to get execution time, ° d ONLN d”0°<˛ (Xøyou must execute a ° d ONLN dÊ< <H™ (d ZIQuickDraw drawing routine that calls one of the grafProcs. In this case, ° d ONLN d/<™H˛ (d»the MoveTo/Line ° d ONLN d?H <T z (p Z combination ° d ONLN dKH zT˛ )>Ois sent firing the StdLine grafProc. When StdLine executes, it notices that the ° d ONLN dõT <`Ê (| Z]GrafPort has been reinitialized, and therefore initializes the clipping region for the port. ° d ONLN d¯TÊ`˛ (|Until ° d ONLN d˛` <l¬ (à ZTthe MoveTo/Line combination is executed, the clipping region for the port is set to ° d ONLN d R`¬l˛ (à‡
(0,0,0,0). If ° d ONLN d `l <x≥ (î ZMPostScript code is sent via the PostScriptHandle PicComment before executing ° d ONLN d ≠l≥x˛ (î—
any QuickDraw ° d ONLN d ªx <Ñ≠ († ZQroutines, all PostScript operations will be clipped to (0,0,0,0). The next thing ° d ONLN d
x≠Ñ˛ (†Àto do is send the ° d ONLN d
Ñ <ê! (¨ Z,PostScriptBegin PicComment. This comment is ° d ONLN d
JÑ!ê˛ )Â.recognized only by PostScript printer drivers. ¡ X¡
° d ONLN d ) 7 *When ° d ONLN d 7 )⁄ ) Ythe driver receives this comment, it saves the current state of the PostScript device (by ° d ONLN d _ ) 5+ ( Q 68executing the PostScript gsave operator), then disables ° d ONLN d ó )+ 5⁄ ( QI!all QuickDraw drawing operations. ° d ONLN d π 5 A! ( ] 66This way, the QuickDraw representation of the Graphic ° d ONLN d Ô 5! A⁄ ( ]?&will be ignored by PostScript devices. ° d ONLN d A M ê ( i 6In the previous example, ° d ONLN d/ A ê M⁄ )x@the MoveTo/LineTo combination is only executed on non-PostScript ° d ONLN dp M Y ß ( u 6 devices. The next comment is ° d ONLN dç M ß Y⁄ )è?the PostScriptHandle PicComment. This tells the driver that the ° d ONLN dÕ Y e ∂ ( Å 6"data in thePSHandle is to be sent ° d ONLN dÔ Y ∂ e⁄ )û=to the device as PostScript code. The driver then passes this ° d ONLN d- e q g ( ç 6code unchanged ° d ONLN d< e g q⁄ )OJto the PostScript device for execution. The PostScriptHandle PicComment is ° d ONLN dá q }¥ ( ô 6Sonly recognized by PostScript printer drivers. The last PicComment, PostScriptEnd, ° d ONLN d⁄ q¥ }⁄ ( ô“ tells the ° d ONLN d‰ } â f ( • 6driver to restore ° d ONLN dˆ } f â⁄ )NPthe previous state of the device (via a PostScript grestore call), and to enable ° d ONLN dG â ï ‘ ( ± 6$QuickDraw drawing operations. Since ° d ONLN dk â ‘ ï⁄ )º1all PicComments are ignored by QuickDraw devices, ° d ONLN dù ï ° ( Ω 64only the QuickDraw representation is printed. Since ° d ONLN d— ï °⁄ )˜+PostScriptBegin tells PostScript drivers to ° d ONLN d˝ ° ≠ñ ( … 6Kignore QuickDraw operations, only the PostScript representation is printed ° d ONLN dH °ñ ≠⁄ ( …¥
on PostScript ° d ONLN dV ≠ π ¸ ( ’ 6,devices. This is a truly device-independent ° d ONLN dÇ ≠ ¸ π⁄ )‰(method for providing both PostScript and ° d ONLN d´ π ≈ ‚ ( · 6(QuickDraw representations of a document.
° d ONLN d‘ › Ï} *'5Converting PostScript file to Encapsulated PostScript
° d ONLN d
Ï ¯ Ä * Date Written: 5/19/92 ° d ONLN d! ¯ á * Last reviewed: 6/14/93 ° d ONLN d9 C *9What needs to be added to an ordinary PostScript file to ° d ONLN drC ⁄ (8a convert it to an Encapsulated ° d ONLN dê ( Ä (D 6PostScript (EPS) file? ° d ONLN dß( 4 * * ___ ° d ONLN d´@ L *1The latest Adobe “red book,” PostScript Language ° d ONLN d‹@L⁄ )˘'Reference Manual (2nd Edition), has the ° d ONLN dL XÆ (t 6Rinformation you need. Appendix H: Encapsulated PostScript File Format Version 3.0 ° d ONLN dVLÆX⁄ (tà describes ° d ONLN d`X d[ (Ä 6>the contents of an EPS file. Appendix G: Document Structuring ° d ONLN dûX[d⁄ (ÄyConventions specifies the ° d ONLN d∏d pé (å 6Msingle-page document PS file, which must include at least these two comments: ,
Courier
° d ONLN d| á ü * %!PS-Adobe-3.0 EPSF-3.0 ° d ONLN d"Ü ë ¬ *
" %%BoundingBox: llx lly urx ury
° d ONLN dEú ®X *BYou might find the following references from Adobe useful as well: ° d ONLN dॠ¿œ *X Adobe Illustrator Document Format Specification v2.0 (Adobe Technical Note #LPS5007) ° d ONLN d·¿ Ãs * F Encapsulated PostScript Files v1.2 (Adobe Technical Note #LPS5002) ° d ONLN d(ÿ ‰ ã *You can reach Adobe at: ° d ONLN d@ ¸ ï * Corporate Headquarters ° d ONLN d[¸ ÷ * % 1585 Charleston Road, PO Box 7900 ° d ONLN dÅ ¡ * Mountain View, CA 94039-7900 ° d ONLN d¢ À * $ (415) 961-4111 Developer Support ° d ONLN d«, 8 Ç *Macintosh Technical ° d ONLN d€, Ç8⁄ )j=Note “Picture Comments—The Real Deal” (formerly #91) contains ° d ONLN d 8 D< (` 6<sample code for using all of the supported Picture Comments.
° d ONLN d V\ kA *'+Printing halftone images on the LaserWriter
° d ONLN d Çk w z * Date Written: 5/3/89 ° d ONLN d òw É Å * Last reviewed: 8/1/92 ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ) › ( E Z How can I print halftone images ° d ONLN d › )˛ )°7on the LaserWriter? How do I use the PostScript “image” ° d ONLN d X ) < 5 œ ( Q Z operator for printing halftones? ° d ONLN d y 5 < A N * ___ ° d ONLN d } M < Y` *<The PostScript “image” operator is similar to the Macintosh ° d ONLN d π M` Y˛ ( u~ QuickDraw CopyBits routine. It ° d ONLN d ÿ Y < e Q ( Å Zcan ° d ONLN d ‹ Y Q e˛ )Pbe used by converting a QuickDraw bitmap/pixmap into an image call. This is only ° d ONLN d- e < q y ( ç Z
necessary if ° d ONLN d: e y q˛ )=Pyou are printing color information with a PostScript printer driver that doesn’t ° d ONLN dã q < } Å ( ô Zsupport Color ° d ONLN dô q Å }˛ )EHQuickDraw. LaserWriter drivers up to 5.2 do NOT support Color QuickDraw. ° d ONLN d‚ } < âW ( • Z<If you want to send color information to a LaserWriter with ° d ONLN d }W Ⲡ( •u#version 5.2 of the driver, you will ° d ONLN dB â < ïı ( ± ZYhave to convert your color images into image commands. Before doing this it is important ° d ONLN dõ âı ï˛ ( ±to ° d ONLN dû ï < ° o ( Ω Z
check the ° d ONLN d® ï o °˛ )3KGrafPort returned by PrOpenDoc. If this port is a Color QuickDraw port (for ° d ONLN dÙ ° < ≠ï ( … ZDexample, portBits.rowBytes < 0) then you should use Color QuickDraw ° d ONLN d8 °ï ≠˛ ( …≥commands and let the ° d ONLN dM ≠ < π ( ’ Z+driver handle the conversion to PostScript. ° d ONLN dy ≈ < —‡ *NAbout image: The PostScript image operator is used to send bitmaps or pixmaps ° d ONLN d« ≈‡ —˛ ( Ì˛to the ° d ONLN dŒ — < ›› ( ˘ ZXLaserWriter. The image operator can handle depths from one to eight bits per pixel. Our ° d ONLN d& —› ›˛ ( ˘˚current ° d ONLN d. › < Èw ( Z=LaserWriters can image only about 16 shades of gray, but the ° d ONLN dk ›w È˛ (ïprinted page will look like ° d ONLN dá È < ı] ( Z?there’s more. Because the image operator is still a PostScript ° d ONLN dΔ È] ı˛ ({$operator, it expects its data in the ° d ONLN dÎ ı < † ( Zform of hexadecimal ° d ONLN dˇ ı †˙ )dEbytes. The bytes are represented by two ASCII characters(“0”-”9,” “A” ° d ONLN dD ı˙˛ ( - ° d ONLN dE <
° d ONLN d‰ç <ô0 *4In the preceding example, the width of the image is ° d ONLN dç0ô˛ )Ù+640, the height is 480, and the depth is 8. ° d ONLN dDô <• Æ (¡ ZThe matrix (enclosed in ° d ONLN d\ô Æ•˛ )rEbrackets) is set up to draw the image starting at QuickDraw’s 0,0(top ° d ONLN d¢• <±â (Õ ZEleft of page), and with no scaling. The PostScript code (enclosed in ° d ONLN dÁ•â±˛ (Õßbraces) is not executed. ° d ONLN d ± <Ωt (Ÿ ZDInstead, it is passed to the image operator, and the image operator ° d ONLN d D±tΩ˛ (Ÿí calls it repeatedly until it has ° d ONLN d eΩ <…Æ ( ZLenough data to draw the image. In this case, it is expecting 640*480 bytes. ° d ONLN d ±ΩÆ…˛ (ÂÃWhen the image ° d ONLN d ¿… <’) (Ò Z4operator calls the procedure, it does the following: ° d ONLN d ı· <Ì F *1. ° d ONLN d ¯· NÌ≥ )KPushes the current file which in this case is the stream of data coming to ° d ONLN d
C·≥Ì˛ ( —the LaserWriter ° d ONLN d
SÌ N˘§ ( lJover AppleTalk. This is the first parameter to the readhexstring operator. ° d ONLN d
û < F (- Z2. ° d ONLN d
° NW )6Pushes picstr. picstr is a string variable defined to ° d ONLN d
◊W˛ (-u hold one row of hex data. The ° d ONLN d
ı N Â (9 l#PostScript to create the picstr is:
° d ONLN d ) N4 ô */picstr 640 def
° d ONLN d *? <K F (g Z3. ° d ONLN d -? NK ú )readhexstring is ° d ONLN d >? úK˛ )NNcalled to fill picstr with data from the current file. It begins reading bytes ° d ONLN d çK NWN (s l6which are the characters following the image operator. ° d ONLN d ƒc <o F (ã Z4. ° d ONLN d «c No¡ )Nreadhexstring leaves the string we want, and a boolean that we don’t want, on ° d ONLN d c¡o˛ (ãfl
the stack, so ° d ONLN d #o N{ (ó l'we do one pop to kill off the boolean. ° d ONLN d Jo{˛ )µ4Now the string is left behind for the image operator ° d ONLN d { Ná n (£ lto use. ¡ X¡
a nice job of ° d ONLN dÛ ° ≠ ( … 63converting lower resolution images to 8 bits/pixel. ° d ONLN d' π ≈ « *'Build a color table: An eight bit deep ° d ONLN dN π « ≈⁄ )Ø7image can use only 256 colors. Since the image that you ° d ONLN dÜ ≈ —> ( Ì 6;are starting with is probably color, and the image you get ° d ONLN d¡ ≈> —⁄ ( Ì\ will be grayscale, you need to ° d ONLN d‡ — › Í ( ˘ 6-convert the colors in the source color table ° d ONLN d
— Í ›⁄ )“2into PostScript grayscale values. This is actually ° d ONLN d@ › È» ( 6Zeasy to do using the Color Manager. First create a table that can hold 512 bytes. This is ° d ONLN dö ›» È⁄ (Êtwo ° d ONLN dû È ı À ( 6%bytes for each color value from 0 to ° d ONLN d√ È À ı⁄ )≥4255. Since PostScript wants the values in ASCII, you ° d ONLN d¯ ı À ( 6$need two characters for each pixel. ° d ONLN d ı À⁄ )≥4Now loop through the colors in the color table. Call ° d ONLN dQ
t () 6Index2Color to get ° d ONLN dd t
⁄ )\Gthe real RGB color for that index, and then call RGB2HSL to convert the ° d ONLN d¨
ø (5 6"RGB color into a luminance value. ° d ONLN dŒ
ø⁄ )ß9This value is expressed as a SmallFract which can then be ° d ONLN d %' (A 6:scaled into a value from 0 to 255. This value should then ° d ONLN dB'%⁄ (AE$be converted to ASCII, and stored at ° d ONLN dg% 1 ˇ (M 60the appropriate location in the table. When you ° d ONLN dó% ˇ1⁄ )Á+are done, you should be able to use a pixel ° d ONLN d√1 = ≥ (Y 6"value as an index into your table ° d ONLN dÂ1 ≥=⁄ )õ=of PostScript color values. For each pixel in the image, send ° d ONLN d#= I ∏ (e 6"two characters to the LaserWriter. ° d ONLN dFU aò *VSending the data: Once you have set up the color table, all that’s left to do is loop ° d ONLN dúUòa⁄ (}∂through all of ° d ONLN d´a mè (â 6Othe pixels, and send their PostScript representation to the LaserWriter. There ° d ONLN d˙aèm⁄ (â≠are a couple of ° d ONLN d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å7 ( õ Z PR 510 - Printer Driver Q&As
° d ONLN d Ä < è s *Printing
° d ONLN d ' õ < ß t * Revised by: ° d ONLN d 3 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d L õ± ߲ ( √œSeptember 1993 ° d ONLN d [ ß < ≥ q ( œ Z Written by: ° d ONLN d g ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d Ä ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d ç ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ¨ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ê À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d- À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN d@ ◊ < „ u ( ˇ Z
While DSC ° d ONLN dJ ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dó „ < Ô q ( Z don’t have ° d ONLN d¢ „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dÙ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dI ˚ < (# Z,information migrates into reference manuals. ° d ONLN dv < k *:Q&As are now included with Technical Notes to make access ° d ONLN d∞k ˛ (;â to technical updates easier for ° d ONLN d– <+. (G Z/you. If you have comments or suggestions about ° d ONLN dˇ .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d*+ <7 \ (S Zknow ° d ONLN d/+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dy7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN d≥O <[ · * New Q&As in this Technical Note: ° d ONLN d‘[ <g * +Defining default LaserWriter Pro paper tray ° d ONLN d g <s Ô * &Code for getting selected printer name ° d ONLN d's < ” * !StyleWriter II driver differences ° d ONLN dI <ã Æ * Determining printer font ∂ X∂
° d ONLN db∞ <øg *4+Defining default LaserWriter Pro paper tray
° d ONLN déø <À ß * Date Written: 5/17/93 ° d ONLN d¶À <◊ ® * Last reviewed: 5/19/93 ° d ONLN dΩ„ <Ô q *
file for your ° d ONLN dgs < l (õ Z printer to ° d ONLN drs l˛ )0Qchange these relationships. LaserWriter 8.0 requires files that meet the PPD 4.0 ° d ONLN dƒ <ãw (ß Z@specification, available from Adobe’s Developer Support program. ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øn ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 8 *'&Code for getting selected printer name
° d ONLN d ' 8 D É * Date Written: 3/10/93 ° d ONLN d ? D P Ñ * Last reviewed: 6/24/93 ° d ONLN d V \ hÑ *MHow do I get the name of the currently selected printer, for Systems 6 and 7? ° d ONLN d § h t * * ___ ° d ONLN d ® Ä å » *%The printer driver has a resource of ° d ONLN d Õ Ä » å⁄ )∞3type PAPA, ID -8192, which contains the name of the ° d ONLN d å ò Î ( ¥ 6.selected printer and the network object type. ° d ONLN d/ å Î ò⁄ )”1This resource is amazingly easy to get; you don’t ° d ONLN da ò §» ( ¿ 6Weven need to know where the printer driver resource file is located. Just call PrOpen. ° d ONLN d∏ ò» §⁄ ( ¿ÊThe ° d ONLN dº § ∞ ⁄ ( à 6)Printing Manager will open the currently ° d ONLN d § ⁄ ∞⁄ )¬8selected printer driver for you, and place it at the top ° d ONLN d ∞ ºë ( ÿ 6Gof the resource chain. Then see whether you can GetResource for 'PAPA' ° d ONLN de ∞ë º⁄ ( ÿØ
ID -8192, and ° d ONLN ds º » Ô ( ‰ 6,viola—you have a handle to the printer name. ° d ONLN d† ‘ ‡ d *This will work ° d ONLN dØ ‘ d ‡⁄ )LCunder both System 6 and System 7. However, under QuickDraw GX, this ° d ONLN dÛ ‡ Ï Å ( 6method is subject to ° d ONLN d ‡ Å Ï⁄ )iEchange. Also note that this is a read-only field; changing it doesn’t ° d ONLN dN Ï ¯ œ ( 6(necessarily change the selected printer. ° d ONLN dw ù * The printer name is the first ° d ONLN dï ù⁄ )ÖEstring, and the object type is packed right up against it. If all you ° d ONLN d€ 5 (8 6?want is the name, then here’s a C routine that will provide it: ,
Courier
° d ONLN d( 3 « *#OSErr GetPrinterName(Str255 prName) ° d ONLN d?2 = *
{ ° d ONLN dA< G Ü *
OSErr err = noErr; ° d ONLN dXF Q ï *
char **papaDataHandle; ° d ONLN drZ e O * PrOpen(); ° d ONLN d~n y ˛ *. papaDataHandle = Get1Resource('PAPA',-8192); ° d ONLN d≠Ç ç ã * if(!papaDataHandle) { ° d ONLN d≈å ó Å *
- ReleaseResource((Handle) papaDataHandle); ° d ONLN dR¥ ø ' *
} ° d ONLN dV» ” T * PrClose(); ° d ONLN dc‹ Á Y *
return err; ° d ONLN dqÊ Ò *
}
° d ONLN ds ı *&!StyleWriter II driver differences
° d ONLN dï # É * Date Written: 3/17/93 ° d ONLN d≠# / Ñ * Last reviewed: 6/24/93 ° d ONLN dƒ; G] *AMy application won’t print to a StyleWriter II although it works ° d ONLN d;]G⁄ (c{fine on all other printers ° d ONLN d G Sì (o 6Lincluding the original StyleWriter. Can you give me any suggestions? What’s ° d ONLN dlGìS⁄ (o±different about ° d ONLN d|S _ o ({ 6the StyleWriter II? ° d ONLN dê_ k * * ___ ° d ONLN dîw É î *The StyleWriter II driver ° d ONLN dÆw îÉ⁄ )|?is a member of the “GrayShare” driver family, with new features ° d ONLN dÓÉ è ” (´ 6'such as support for grayscale printing ° d ONLN dÉ ”è⁄ )ª5(if Color QuickDraw is available) and printer sharing ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ) Õ ( E Z over the network. Its internal ° d ONLN d Õ )˛ )ë@architecture is very different from previous printer drivers. In ° d ONLN d ` ) < 5 U ( Q Zspite ° d ONLN d f ) U 5˛ )Wof thorough compatibility testing, some problems have shown up since the first release. ° d ONLN d æ 5 < A I ( ] ZIn ° d ONLN d ¡ 5 I A˛ )
Ymany cases, the driver revealed weaknesses in the applications themselves; for some other ° d ONLN d A < M¡ ( i ZRproblems, a solution will be incorporated in the next release of the driver. Here ° d ONLN dm A¡ M˛ ( ifl
are currently ° d ONLN d{ M < Y< ( u Z8identified problem areas with the StyleWriter II driver: ° d ONLN d¥ e < q @ *• ° d ONLN d∂ e E qú ) FThe StyleWriter II driver handles memory differently. For example, if ° d ONLN d¸ eú q˛ ( ç∫an application has a ° d ONLN d q E }ë ( ô cEdereferenced handle to an unlocked block while CopyBits’ing into the ° d ONLN dV që }˛ ( ôØprinting port, this may ° d ONLN dn } E â – ( • c work fine on all other printer ° d ONLN dç } – Ⲡ)ã@drivers, but the block is likely to move with the StyleWriter II ° d ONLN dŒ â E ï ( ± c*driver, and the results are unpredictable. ° d ONLN d˘ ° < ≠ @ ( … Z• ° d ONLN d˚ ° E ≠õ ) GThe StyleWriter II driver maintains its own A5 world internally. If an ° d ONLN dB °õ ≠˛ ( …πapplication installs a ° d ONLN dY ≠ E π ( ’ cNgrowZone proc and forgets to set up its own A5 in the growZone proc (ignoring ° d ONLN dß ≠ π˛ ( ’the ° d ONLN d´ π E ≈ ë ( · cTechnical Note ° d ONLN d∫ π ë ≈˛ )LC“Register A5 Within GrowZone Functions”), the growZone proc may get ° d ONLN d˛ ≈ E —… ( Ì cTcalled with the StyleWriter II driver’s A5, which obviously is bad for the survival ° d ONLN dR ≈… —˛ ( ÌÁ of both the ° d ONLN d^ — E › ‚ ( ˘ c#application and the printer driver. ° d ONLN dÇ È < ı @ ( Z• ° d ONLN dÑ È E ı Z ) The ° d ONLN dà È Z ı˛ )YStyleWriter II driver calls the pIdleProc (in the job subrecord of the print record) more ° d ONLN d‚ ı E Ô ( c"often than other printer drivers; ° d ONLN d ı Ô˛ )™3in particular, it may be called during execution of ° d ONLN d8 E
() c-PrOpenDoc. If an application reloads a print ° d ONLN de
˛ )”.record previously used, containing an old (now ° d ONLN dî
Efl (5 cOinvalid) pointer to an idleProc, and doesn’t update the pIdleProc field before ° d ONLN d„
fl˛ (5˝calling ° d ONLN dÎ E% Õ (A c PrOpenDoc, disaster is very ° d ONLN d Õ%˛ )à?likely. Note that the TechNote “pIdle Proc (or how to let users ° d ONLN dG% E1 å (M c know what’s ° d ONLN dS% å1˛ )GFgoing on during print time)” recommends installing the idleProc before ° d ONLN dö1 E= Ä (Y c
° d ONLN d < ü * Date written: 1/26/93 ° d ONLN d
<$ ® * Last reviewed: 4/26/93 ° d ONLN d
0 <<v *COur application must print with Helvetica if available, and Geneva ° d ONLN d
`0v<˛ (Xîif not. How can I determine ° d ONLN d
|< <HØ (d ZNwhich fonts are available in a printer? I’ve been using the wDev field in the ° d ONLN d
<ØH˛ (dÕprint record and ° d ONLN d
€H <T § (p Zassuming that a value ° d ONLN d
ÒH §T˛ )hIof 3 means Helvetica will print correctly, but according to “Print Hints: ° d ONLN d ;T <` „ (| Z!Top 10 Printing Misdemeanors” in ° d ONLN d \T „` )ßdevelop ° d ONLN d cT`û )%! issue 12, this isn’t dependable. ° d ONLN d Ö` <l N (à Z___ ¡ X¡
° d ONLN dπ (Ö *'6Where to get PostScript Printer Definition (PPD) files
° d ONLN d( 4 x * Date written: 2/9/93 ° d ONLN d4 @ Å * Last reviewed: 4/1/93 ° d ONLN d L Xº *ZWhere can I get PostScript Printer Definition (PPD) files for Apple’s PostScript printers? ° d ONLN dxX d * * ___ ° d ONLN d|p |¨ *SApple recently made PPD files for its printers—past and present—available. You can ° d ONLN dœp¨|⁄ (ò find them ° d ONLN dŸ| àÄ (§ 6Con AppleLink in the Software Sampler: Apple SW Updates: Macintosh: ° d ONLN d |Äà⁄ (§ûPrinting Software: ° d ONLN d/à î V (∞ 6 PPDs folder. ° d ONLN d<† ¨ È *,PPD files for non-Apple PostScript printers ° d ONLN dh† Ȩ⁄ )—-with ROMs by Adobe Systems are available from ° d ONLN dñ¨ ∏ ù (‘ 6a clearinghouse maintained ° d ONLN d±¨ ù∏⁄ )Ö<by Adobe. To request a PPD file from Adobe, send an internet ° d ONLN dÓ∏ ƒè (‡ 6Gmessage to “ps-file-server@adobe.com” with the subject “help”. Adobe’s ° d ONLN d5∏èƒ⁄ (‡≠list server will ° d ONLN dFƒ –¶ (Ï 6Trespond with mail about items available on the list server and how you can get them.
° d ONLN d»˜ ~ * Date written: 1/11/93 ° d ONLN dfl Å * Last reviewed: 4/1/93 ° d ONLN dˆ ' Í **Is LaserWriter Driver 7.2 ColorSync aware? ° d ONLN d !' 3 * * ___ ° d ONLN d %? Ki *ENo, LaserWriter Driver 7.2 isn’t ColorSync aware. Apple plans to add ° d ONLN d j?iK⁄ (gáColorSync capability to ° d ONLN d ÇK Wq (s 6Ffuture versions of the LaserWriter driver, but we don’t have any more ° d ONLN d »KqW⁄ (sèinformation or details ° d ONLN d flW c D ( 6
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ,9 ( H Z$Printing nonstandard page dimensions
° d ONLN d % , < 8 ¢ * Date written: 1/14/93 ° d ONLN d < 8 < D ´ * Last reviewed: 6/14/93 ° d ONLN d T P < \ › * How do we override the standard ° d ONLN d t P › \˛ )°<page dimensions for the StyleWriter or, for that matter, any ° d ONLN d ± \ < h{ ( Ñ ZFother printer? We want to print 5.5" x 8.5" (half letter-sized) pages. ° d ONLN d ¯ h < t N * ___ ° d ONLN d ¸ Ä < å ù *The current printing ° d ONLN d Ä ù åù )a6architecture isn’t designed for elegant (or sometimes ° d ONLN dG Äù å≤ ( ®ªany) ° d ONLN dK Ä≤ å˛ ) communication ° d ONLN dZ å < ò6 ( ¥ Z7from your program to the printer driver. All the calls ° d ONLN dë å6 ò˛ )˙%you normally make (such as PrOpenDoc, ° d ONLN d∑ ò < §Ö ( ¿ ZEPrOpenPage, and PrPicFile) are handled by the printer driver and not ° d ONLN d¸ òÖ §˛ ( ¿£by the Printing Manager. ° d ONLN d § < ∞ ≠ ( à ZThe drivers manage the ° d ONLN d, § ≠ ∞˛ )qEprint records, put up the dialog boxes, decide how to render graphics ° d ONLN dr ∞ < º≠ ( ÿ ZOand everything else in between. That’s why writing a printer driver is so hard. ° d ONLN d¬ » < ‘£ *RIf you want to tell a printer driver “I want to use this size paper,” that driver ° d ONLN d »£ ‘˛ ( ¡has to implement a ° d ONLN d' ‘ < ‡L ( ¸ Z:driver-specific way to do it or it can’t be done. There’s ° d ONLN da ‘L ‡˛ ( ¸j$no PrSetPageSize call in the current ° d ONLN dÜ ‡ < Ï° ( ZLprinting architecture. In fact, trying to print outside the rPage rectangle ° d ONLN d“ ‡° Ï˛ (øcan cause physical ° d ONLN dÂ Ï < ¯– ( ZPdamage on some printers, so customizing page sizes is not something you want to ° d ONLN d5 Ï– ¯˛ (Ó
enter into ° d ONLN d@ ¯ < ^ ( Zlightly. ° d ONLN dI < Ô *^You can’t change the paper size in the print record, because most drivers don’t look there to ° d ONLN dßÔ ˛ (8
see ° d ONLN d´ <( k (D Z
what size ° d ONLN dµ k( Å )/you ° d ONLN dπ Å( õ )want; ° d ONLN dæ õ(K )% instead they tell you what size you ° d ONLN d„ K(] )∞get ° d ONLN dÁ ](˛ )#in that field. The same is true for ° d ONLN d ( <4 ’ (P Z!most of the print record: Unless ° d ONLN d,( ’4& )ôInside Macintosh ° d ONLN d<(&4} )Q tells you that you ° d ONLN dP(}4˛ )W can write to that field, you ° d ONLN dm4 <@ ı (\ Z&can’t (or doing so won’t do any good). ° d ONLN dîL <Xß *QThe StyleWriter in particular has very limited paper options; it handles letter, ° d ONLN dÂLßX˛ (t≈legal, A4, and B5 ° d ONLN d˜X <dH (Ä Z<paper sizes—and that’s it. If you try to print other sizes, ° d ONLN d3XHd˛ (Äf&the hardware reports an error. This is ° d ONLN dZd <p— (å ZRpretty common in these days of very low-cost high-quality printers; features that ° d ONLN d¨d—p˛ (åÔyou as a ° d ONLN dµp <| ∑ (ò Zprogrammer would want ° d ONLN dÀp ∑|˛ ){Bare jettisoned to keep the cost down. Most low-cost laser printers ° d ONLN d| <à! (§ Z2have limited paper-handling capabilities as well. ° d ONLN d@|!à˛ )Â.If you try to print continuous feed paper on a ° d ONLN doà <î µ (∞ ZStyleWriter, you’ll get a ° d ONLN dâà µî˛ )yApaper jam error after about 15 inches of paper pass through (long ° d ONLN dÀî <†Ô (º Z_enough for the printer to realize it’s not legal-sized paper). Your half-letter size pages are ° d ONLN d*îÔ†˛ (º
too ° d ONLN d.† <¨ ª (» Z short for the printer to use. ° d ONLN dL∏ <ƒ … *While QuickDraw GX has a ° d ONLN de∏ …ƒ˛ )ç?much more robust printing architecture, that doesn’t help right ° d ONLN d•ƒ <–µ (Ï ZMnow for the current world. Something that you may wish to consider is making ° d ONLN dÚƒµ–˛ (Ï”forms available ° d ONLN d – <‹è (¯ ZIon regular letter-sized paper, with two per sheet. That size paper works ° d ONLN d K–è‹ú (¯≠in ° d ONLN d N–ú‹∂ )
every ° d ONLN d S–∂‹˛ ) printer sold in ° d ONLN d d‹ <Ëï ( ZHthe United States and could be perforated and detached by the customers. ° d ONLN d ≠Ù < F *9All of Apple’s LaserWriter printers have excellent paper ° d ONLN d ÊÙF ˛ ( d&handling but cost relatively more. The ° d ONLN d
< (( Z/best way to handle custom page printing across ° d ONLN d
< ) )‚all ° d ONLN d
? ) j ) printers is to ° d ONLN d
O j ˛ )A place your custom-sized image ° d ONLN d
m <# (4 Z0on an 8.5" x 11" page and provide special paper. ° d ONLN d
û$ <0≤ *OMany, but not all, of Apple’s printers support a PREC 3 resource that contains ° d ONLN d
Ì$≤0˛ (L–extra page sizes ° d ONLN d
˛0 <<] (X Z>in a custom format. The format of this resource is as follows: ,
Courier
° d ONLN d =H <S ¥ * PageSizeRecord = RECORD ° d ONLN d VR <] † *
numItems: INTEGER; ° d ONLN d k\ <g6 *
2 botRights: ARRAY [0..NumPageOptionsZB] OF Point; ° d ONLN d ûf <q ˙ *
& titles: PACKED ARRAY [0..0] OF CHAR; ° d ONLN d ≈p <{ U *
° d ONLN d ) *2numItems is the number of page sizes displayed in ° d ONLN d 2 )⁄ )˙%the dialog. The maximum number is six ° d ONLN d X ) 5 Û ( Q 60(since there is only room for six radio buttons ° d ONLN d à ) Û 5⁄ )€0in the Page Setup dialog). botRights is an array ° d ONLN d π 5 Aü ( ] 6Uof points specifying the bottom right corner for each page. This corner is specified ° d ONLN d 5ü A⁄ ( ]Ω in 120ths of ° d ONLN d A M ≠ ( i 6 an inch, and it should define ° d ONLN d9 A ≠ M⁄ )ï;the physical size of the paper, not the imageable area. For ° d ONLN du M Y ƒ ( u 6%example, U.S. Letter is specified as: ,
Courier
° d ONLN dõ e p Ô *+ bottom = 1320(11"), right = 1020(8.5").
° d ONLN d» { á ê * titles is a packed array of ° d ONLN d‰ { ê á⁄ )xApage size names. Each name begins with a length byte, followed by ° d ONLN d& á ì ˇ ( Ø 6*the number of characters specified by the ° d ONLN dP á ˇ ì⁄ )Á'length byte. The strings are packed, so ° d ONLN dx ì üs ( ª 6Fstring1[LENGTH(string1)+1] would reference the length byte of string2. ° d ONLN d¿ ´ ∑ § * To use this mechanism, your ° d ONLN d‹ ´ § ∑⁄ )å=application should create a PREC resource with an ID = 4. You ° d ONLN d ∑ √
( fl 61can do this very easily by copying PREC(3). Once ° d ONLN dK ∑
√⁄ )Ú(you have a copy, you can modify the page ° d ONLN dt √ œ[ ( Î 6Dsizes as you wish. When the printer driver is called to display the ° d ONLN d∏ √[ œ⁄ ( ÎyPage Setup dialog, it will ° d ONLN d” œ € ( ˜ 6;first look for PREC(4). If found, it will use it to define ° d ONLN d œ €⁄ ( ˜<(the page sizes. If not found, the driver ° d ONLN d7 € Á “ ( 6'will use the standard sizes in PREC(3). ° d ONLN d_ Û ˇ *,This method only works with some of Apple’s ° d ONLN dã Û ˇ⁄ )Ë-drivers; the LaserWriter driver ignores these ° d ONLN dπ ˇ (' 66resources. If you decide to implement this feature in ° d ONLN dÔ ˇ ⁄ ('7&your application, be sure to warn your ° d ONLN d G (3 6Ausers that custom page sizes may not be available on all devices. ° d ONLN dX# / â *Use this feature at your ° d ONLN dq# â/⁄ )qCown risk; it’s very likely not to work under QuickDraw GX and later ° d ONLN dµ/ ; i (W 6system software.
° d ONLN dΔS bo *'2LaserWriter driver 'feed' resource troubleshooting
(Δ 62redefined showpage is executed the variables that ° d ONLN dû
™⁄ )Ú*should have been defined the first time in ° d ONLN d9™ ∂æ (“ 6Uuserdict are unbound. What could be happening here? How should I define something in ° d ONLN dé™æ∂⁄ (“‹'feed' ° d ONLN dï∂ ¬f (fi 6Hresource code that acts like a global variable for a redefined showpage? ° d ONLN dfi¬ Œ * * ___ ° d ONLN d‚⁄ Ê “ *&Your operators shouldn’t be wiped out ° d ONLN d⁄ “Ê⁄ )∫3with each page. You’re being loaded before the PREC ° d ONLN d<Ê Ú ı ( 6,103 is loaded and before the series of save ° d ONLN dhÊ ıÚ⁄ )›-and restore operators are called, which could ° d ONLN dñÚ ˛ æ ( 6 otherwise wipe you out. Please ° d ONLN dµÚ æ˛⁄ )¶1read the Macintosh Technical Note “The Lo Down on ° d ONLN dÁ˛
Å (& 6KDictionary Downloading” for a robust description of this process. Thus, we ° d ONLN d 2˛Å
⁄ (&ümust look to other ° d ONLN d E
(2 6/reasons why your operators are being wiped out. ° d ONLN d u" . · *,The natural culprit is your PostScript. Are ° d ONLN d °" ·.⁄ )…0you wiping yourself out? Second, you should heed ° d ONLN d “. : ‚ (V 6%the warning on page 4 of the “Feeder ° d ONLN d ˜. ‚:⁄ ) .Fodder” Technical Note: “As always, calling or ° d ONLN d
&: F
(b 63redefining operators defined by the LaserPrep (md) ° d ONLN d
Y:
F⁄ )ı*dictionary isn’t supported.” You could see ° d ONLN d
ÑF RW (n 6Cproblems as you describe if you’re redefining LaserPrep dictionary ° d ONLN d
«FWR⁄ (nucommands. Other variables ° d ONLN d
·R ^ N (z 6 include the ° d ONLN d
ÌR N^⁄ )6Qsystem software and LaserWriter driver versions that you’re using. It could be an ° d ONLN d ?^ j ÷ (Ü 6*issue with the type of LaserWriter itself. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ,Î ( H Z;LaserWriter driver doesn’t SwapMMUMode for 32-bit addresses
° d ONLN d < , < 8 ® * Date written: 11/17/92 ° d ONLN d T 8 < D ´ * Last reviewed: 6/14/93 ° d ONLN d l P < \ › * When I use CopyBits to move a ° d ONLN d ä P › \˛ )°8cGrafPort’s portPixMap to another cGrafPort (my printing ° d ONLN d √ \ < h c ( Ñ Z
port), it ° d ONLN d Õ \ c h˛ )'Pworks like a charm when background printing is turned on, but when CopyBits gets ° d ONLN d h < t ( ê Z,called with background printing turned off, ° d ONLN dJ h t˛ )œ4the image that prints isn’t the image at all. Why is ° d ONLN d t < Ä Ü ( ú Zthis happening? ° d ONLN dè Ä < å N * ___ ° d ONLN dì ò < §î *BYou should be aware that since you’re copying the pixels directly ° d ONLN d’ òî §˛ ( ¿≤from the screen, the ° d ONLN dÍ § < ∞ n ( à Z baseAddr ° d ONLN dÛ § n ∞˛ )2Mpointer for the screen’s pixMap may be 32-bit addressed. In fact, with 32-Bit ° d ONLN dA ∞ < º® ( ÿ ZLQuickDraw, this is the case. This in itself isn’t a problem, since CopyBits ° d ONLN dç ∞® º˛ ( ÿΔknows enough to ° d ONLN dù º < »m ( ‰ Z?access the port’s pixMap’s baseAddr in 32-bit mode, as follows: ,
Courier
° d ONLN d› ‘ < fl á *mode = true32b; ° d ONLN dÌ fi < ÈÜ *
BSwapMMUMode(&mode); // Make sure we're in 32-bit addressing mode. ° d ONLN d0 Ë < ÛJ *
6// Access pixels directly; make no other system calls. ° d ONLN dg Ú < ˝1 *
1SwapMMUMode(&mode); // Restore the current mode.
° d ONLN dô <E *4That’s how you’d normally handle things if you were ° d ONLN dÕE˛ (0c'accessing the pixels directly yourself. ° d ONLN dı < (< Z.Unfortunately, the LaserWriter driver doesn’t ° d ONLN d# ˛ )fl%know enough to do the SwapMMUMode and ° d ONLN dI <,« (H ZUinstead ends up copying garbage (from a 32-bit pointer stripped to a 24-bit pointer). ° d ONLN dü8 <D O *So ° d ONLN d¢8 OD˛ )Lwhy does background printing work? Because when you print in the background, ° d ONLN dÔD <P ÿ (l Z"everything is rolled into a PICT, ° d ONLN dD ÿP˛ )ú=which the driver saves off for PrintMonitor. Since the driver ° d ONLN dOP <\ u (x Z
(Ã Z,call), call OpenPicture, copy the data from ° d ONLN dZ§
∞˛ )—0the screen with CopyBits, call ClosePicture, and ° d ONLN dã∞ <ºÏ (ÿ ZXthen call DrawPicture within your PrOpenPage/PrClosePage loop. That should do the trick. ° d ONLN d‰» <‘Δ *ONote that copying bits directly from the screen is not something we recommend. ° d ONLN d3»Δ‘˛ (‰
Unless you ° d ONLN d>‘ <‡ ” (¸ Z have no alternative, you should ° d ONLN d^‘ ”‡ Ù )óalways ° d ONLN dd‘ Ù‡fi )!3 copy from the original source of the data instead.
° d ONLN dò¯ <` (# Z+System 7.1 and printer driver compatibility
° d ONLN dƒ < ® * Date written: 11/18/92 ° d ONLN d‹ < ´ * Last reviewed: 6/14/93 ° d ONLN dÙ+ <7Δ *OIf a user upgrades from System 7.0.x to 7.1, a new version of the PrintMonitor ° d ONLN d C+Δ7˛ (S‰
is installed. ° d ONLN d Q7 <Cì (_ ZIWill existing printer drivers behave correctly with the new PrintMonitor? ° d ONLN d õC <O N * ___ ° d ONLN d ü[ <g û *When a user installs ° d ONLN d ¥[ ûg˛ )bJSystem 7.1, Easy Install will update any existing printer software. If the ° d ONLN d ˇg <s ∂ (è Zuser picks Customize, he ° d ONLN d
g ∂s˛ )zCor she must choose the printers to be updated. Only the versions of ° d ONLN d
\s <≤ (õ ZNthe printer drivers that come with System 7.1 should be used with 7.1. Mixing ° d ONLN d
° d ONLN d ) *8Since only Apple’s printer drivers use PrintMonitor, as ° d ONLN d 8 )⁄ ( E=$long as you upgrade to System 7.1 by ° d ONLN d ] ) 5 ÷ ( Q 6,using the Installer there’s no issue at all.
° d ONLN d ä M \ *'"System 6 and System 7 PrintMonitor
° d ONLN d ≠ \ h Ñ * Date written: 11/18/92 ° d ONLN d ≈ h t Å * Last reviewed: 3/1/93 ° d ONLN d ‹ Ä å *6Is the version of PrintMonitor that ships with System ° d ONLN d Ä å⁄ ( ®=$7.1 compatible with System 6? If so, ° d ONLN d7 å ò§ ( ¥ 6Qwhich version of the Backgrounder file would be compatible for installation with ° d ONLN dà å§ ò⁄ ( ¥¬
° d ONLN dÚà ó Â *' Which printers to test printing
° d ONLN dó £ ~ * Date written: 10/1/92 ° d ONLN d)£ Ø á * Last reviewed: 11/2/92 ° d ONLN dAª «ô *OWe need to know what printers on which to test our application. It prints only ° d ONLN dêªô«⁄ („∑
pixmaps. It’s ° d ONLN dû« ” ^ (Ô 6been tested on ° d ONLN d≠« ^”⁄ )FJsome LaserWriters. The question is, how many brands and models of printers ° d ONLN d¯” fl> (˚ 6Bdo we need to test it on? Are there any definitive printing tests ° d ONLN d:”>fl⁄ (˚\ (for example, does success on a ° d ONLN dZfl Î ( 65LaserWriter indicate correctness of the application)? ° d ONLN dêÎ ˜ * * ___ ° d ONLN dî > *>Unfortunately, there is no such thing as a universal printing ° d ONLN d“>⁄ (+\ test suite. Moreover, successful ° d ONLN dÛ
(7 62printing not only depends on the specific printer ° d ONLN d%
⁄ )ı)driver (and its version), but also on the ° d ONLN dO ' (C 6.available memory at print time, and on things ° d ONLN d} '⁄ )ÿ1like the font configuration in the system. (Given ° d ONLN dØ' 3 ˚ (O 6.that you print pixmaps only, the last comment ° d ONLN d›' ˚3⁄ )„0is not applicable. Most certainly, all potential ° d ONLN d3 ? ([ 60problems will rather boil down to out of memory ° d ONLN d>3?⁄ )Í,conditions). Also, we have seen applications ° d ONLN dk? K ô (g 6 with severe defects in their ° d ONLN dà? ôK⁄ )ÅEprinting code print quite correctly to the LaserWriter, and fail only ° d ONLN dŒK W ” (s 6'on a few other specific printers. Most ° d ONLN dıK ”W⁄ )ª3other printing problems have to do with assumptions ° d ONLN d )W cl ( 6Jabout the inner working of a specific printer driver, such as hacking the ° d ONLN d sWlc⁄ (äprint record behind the ° d ONLN d ãc o≤ (ã 6Vback of the Printing Manager. In this case, trouble with at least one of the 150 plus ° d ONLN d ·c≤o⁄ (ã– different ° d ONLN d Îo { à (ó 6(printer drivers out there is guaranteed! ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < )E ( E Z6Pragmatically speaking, you may want to test printing ° d ONLN d 6 E )˛ ( Ec'in priority on the printers most likely ° d ONLN d ^ ) < 5 [ ( Q Zbeing ° d ONLN d d ) [ 5˛ ) Oused by your customers. Currently (as of November 1992), this is the PostScript ° d ONLN d ¥ 5 < Av ( ] ZELaserWriter (driver version 7.1.2 or later), the StyleWriter (driver ° d ONLN d ˘ 5v A˛ ( ]î version 7.2.2), the Personal ° d ONLN d A < M y ( i Z LaserWriter ° d ONLN d" A y M˛ )=KLS (driver version 7.2), and one or another of the most popular third-party ° d ONLN dn M < Y ( u ZVprinters. In addition, we recommend that you test both on an older LaserWriter (up to ° d ONLN dƒ M Y˛ ( uthe ° d ONLN d» Y < e ( Å ZLaserWriter II
° d ONLN d÷ Y e å )CNT
° d ONLN dÿ Y å eG )
(), and the newer ones (LaserWriter IIf, ° d ONLN d YG e˛ )ª%IIg, NTR), because of the differences ° d ONLN d& e < q3 ( ç Z6in the PostScript interpreters and gray-level support.
° d ONLN d] â < ò˘ *'@Where to get documentation on writing a Macintosh printer driver
° d ONLN dû ò < § û * Date Written: 4/9/91 ° d ONLN d¥ § < ∞ • * Last reviewed: 8/1/92 ° d ONLN dÀ º < »‚ *UWhere can I find documentation on how to write a Macintosh printer driver equivalent ° d ONLN d º‚ »˛ ( ‰ to the ° d ONLN d' » < ‘, ( Z2ImageWriter or LaserWriter driver? In particular, ° d ONLN dY », ‘˛ )&how are Printing Manager and QuickDraw ° d ONLN dÄ ‘ < ‡/ ( ¸ Z5commands translated into calls to the printer driver? ° d ONLN d∂ ‡ < Ï N * ___ ° d ONLN d∫ ¯ <¬ *CDTS’s “Learning to Drive” document and “StdFileSaver” source code, ° d ONLN d˝ ¯¬˛ ( ‡ available in ° d ONLN d
< (, Z)AppleLink’s Developer Support folder and ° d ONLN d3 C )Õ
on the latest ° d ONLN d@C¨ ): Developer CD Series ° d ONLN dT¨˛ )i disc, are helpful ° d ONLN dg < p (8 Z references.
° d ONLN ds4 <C' *'"Writing a Macintosh printer driver
° d ONLN dñC <O û * Date Written: 5/3/89 ° d ONLN d¨O <[ • * Last reviewed: 8/1/92 ° d ONLN d√g <s ¥ *I have a printer I would ° d ONLN d‹g ¥s˛ )xAlike to connect to the Macintosh. Where can I find information on ° d ONLN d s < ¨ (õ Zwriting a printer driver? ° d ONLN d8 <ã N * ___ ° d ONLN d<ó <£ù *LA Macintosh printer driver is more than a standard device driver. A printer ° d ONLN dàóù£˛ (øªdriver contains code ° d ONLN dù£ <Ø ü (À Zto implement all of ° d ONLN d±£ üØ˛ )cCthe standard Macintosh Printing Manager routines. The code includes ° d ONLN dıØ <ª[ (◊ Z8routines like PrOpen/PrClose, and PrOpenDoc/PrCloseDoc. ° d ONLN d-Ø[ª˛ (◊y!A Printing Resource File contains ° d ONLN dOª <« L („ Zall ° d ONLN dSª L«˛ )Sof the resources (including code) to implement the Macintosh Printing Manager for a ° d ONLN dß« <”T (Ô Z:particular device. A driver works best with all Macintosh ° d ONLN d·«T”˛ (Ôr$applications if it supports both the ° d ONLN d” <fl l (˚ Z
high- and ° d ONLN d” lfl˛ )0Rlow-level Printing Manager interfaces, as well as the PrGeneral (IM V:410) routine ° d ONLN dcfl <Î º ( Zand its associated opcodes. ° d ONLN d˜ <› *XApple is not currently supporting the development of Chooser-selectable device drivers, ° d ONLN d◊˜›˛ ( ˚at least ° d ONLN d‡ < Ó (+ Z'not those that support printers. There ° d ONLN d Ó˛ )≤9are many reasons for this, and here are at least a few of ° d ONLN dA < V (7 Zthem: ° d ONLN dG' <3 ë *First, there is no ° d ONLN dZ' ë3˛ )UIdocumentation or examples available. Each of the Apple printer drivers is ° d ONLN d§3 <?÷ ([ ZWunique. They are all written almost entirely in 68000 assembler, and consequently, are ° d ONLN d˚3÷?˛ ([Ùnot very ° d ONLN d ? <K# (g Z2easy to read. Since each driver is different, the ° d ONLN d 6?#K˛ )Á+only real documentation for how the drivers ° d ONLN d bK <Wæ (s ZSwork is the source code to the driver. There is some general interface information ° d ONLN d µKæW˛ (s‹available, but ° d ONLN d ƒW <cb ( Z=important information, like how the driver manages its print ° d ONLN d
Wbc˛ (Ä record, is described only in the ° d ONLN d
"c <oí (ã ZIsource code. This information could be extracted and distilled into some ° d ONLN d
kcío˛ (ã∞kind of document, but ° d ONLN d
Åo <{ “ (ó Z this brings up the next problem: ¡ X¡
° d ONLN d )0 *:The Macintosh Printing Manager is currently being revised ° d ONLN d : 0 )⁄ ( EN"and enhanced. These revisions will ° d ONLN d ] ) 5 ì ( Q 6require major changes to ° d ONLN d v ) ì 5⁄ ){Dthe architecture of the Printing Manager. It’s not clear what effect ° d ONLN d ª 5 A q ( ] 6these changes will ° d ONLN d Œ 5 q A⁄ )YOhave on existing printer drivers, but it is very possible that the drivers that ° d ONLN d A M≥ ( i 6Xexist today will have to be revised significantly to run under the new Printing Manager. ° d ONLN dw Y eF *8Apple is designing and implementing the next generation ° d ONLN dØ YF e⁄ ( ÅdMacintosh Printing Manager. ° d ONLN dÀ e qR ( ç 6CDevelopers’ suggestions for features are being taken into account. ° d ONLN d eR q⁄ ( çpOne of the goals of the new ° d ONLN d* q }4 ( ô 6=architecture is to make writing drivers much simpler, and to ° d ONLN dg q4 }⁄ ( ôR!allow the sharing of code between ° d ONLN dâ } â _ ( • 6drivers. When ° d ONLN dó } _ â⁄ )GQthis architecture becomes available, Apple will reconsider its position of driver ° d ONLN dÈ â ï ± ( ± 6 development, and will probably ° d ONLN d â ± ï⁄ )ô;end up with some kind of licensing agreement for developers ° d ONLN dD ï °ë ( Ω 6Qthat want to write drivers. Until then, the preceding reasons should be adequate ° d ONLN dï ïë °⁄ ( ΩØjustification for ° d ONLN dß ° ≠ ( … 67NOT attempting a Macintosh printer driver at this time. ° d ONLN dfl π ≈ œ *(If you still aren’t convinced, and want ° d ONLN d π œ ≈⁄ )∑;to write a driver despite the challenge, see the article in ° d ONLN dC ≈ — ñ ( Ì 6the December ’88 issue of ° d ONLN d] ≈ ñ — ƒ )~MacTutor ° d ONLN de ≈ ƒ —ú ).. magazine. There is an example printer driver ° d ONLN dì ≈ú —⁄ )ÿ
written in C. ° d ONLN d° — › ˜ ( ˘ 62It is just a skeleton driver, and does not handle ° d ONLN d” — ˜ ›⁄ )fl/any of the more difficult problems such as line ° d ONLN d › Èt ( 6Nlayout, font substitution, graphics, or banding. But it is a start, and gives ° d ONLN dQ ›t È⁄ (íyou a general idea of ° d ONLN dg È ı ∂ ( 6!the structure of a driver. Since ° d ONLN dà È ∂ ı⁄ )û8some developers began writing their drivers before Apple ° d ONLN d¡ ı : ( 67discontinued support, DTS is still answering questions ° d ONLN d¯ ı:⁄ ( X concerning driver development. ° d ONLN d
w () 6JHowever, these questions are limited to those that can be answered by the ° d ONLN daw
⁄ ()ïDTS engineers. You ° d ONLN dt
ª (5 6"should also be aware that some of ° d ONLN dñ
° d ONLN dfm |ñ *'9Changing printer driver settings without using the dialog
° d ONLN d†| à Ä * Date Written: 11/6/91 ° d ONLN d∑à î á * Last reviewed: 6/14/93 ° d ONLN dœ† ¨ r *To change default ° d ONLN d·† r¨⁄ )ZJprinter driver settings without using the dialog, keep a copy of the print ° d ONLN d,¨ ∏ (‘ 6[record with the various settings you want, and when you want to choose your settings, just ° d ONLN dᨠ∏⁄ (‘Ëuse ° d ONLN dã∏ ƒ V (‡ 6
your special ° d ONLN dò∏ Vƒ⁄ )>Oprint record. The current Macintosh print architecture doesn’t allow procedural ° d ONLN d˃ –D (Ï 6Baccess to the print record, so you must call the dialogs once for ° d ONLN d *ƒD–⁄ (Ïb yourself, choose your settings, ° d ONLN d J– ‹' (¯ 6;and then save a copy of the print record that is produced. ° d ONLN d Ö–'‹⁄ (¯E$Some settings are job-dependent, but ° d ONLN d ™‹ Ë ( 67values that are retrieved from the print record can be ° d ONLN d ·‹Ë⁄ (8%changed using this technique. You can ° d ONLN d
Ë Ù 0 ( 6only ° d ONLN d
Ë 0Ù⁄ )Zsave the settings in the Style dialog. Call PrValidate when retrieving a print record from ° d ONLN d
gÙ ‰ ( 6,the resource fork to make sure it is “good.” ° d ONLN d
ï - *See ° d ONLN d
ô - R )develop ° d ONLN d
† R⁄ )%N, issue #1, pages 58–65, for a complete discussion of changing default printer ° d ONLN d
Ô $ ∞ (@ 6 driver settings and sample code.
° d ONLN d < K *'!Macintosh print record wDev field
° d ONLN d 2K W z * Date Written: 5/3/89 ° d ONLN d HW c Å * Last reviewed: 8/1/92 ° d ONLN d _o {™ *RWhat is the Macintosh print record wDev value for the ImageWriter LQ, LaserWriter ° d ONLN d ±o™{⁄ (ó» IISC, and ° d ONLN d ª{ á r (£ 6AppleFax Modem? ° d ONLN d Àá ì * * ___ ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 5ù ( Q ZIApple strongly discourages the use of the wDev field in the print record ° d ONLN d I )ù 5˛ ( Qªfor several reasons. ° d ONLN d ^ 5 < A ( ] Z'First, this field contains a unique ID ° d ONLN d Ö 5 A˛ )¥5for each printer driver on the Macintosh. Coding your ° d ONLN d ª A < M r ( i Z application ° d ONLN d « A r M˛ )6Oto use this ID makes it device dependent, and device dependence will cause many ° d ONLN d M < Yr ( u Z9problems in the future as the Macintosh Printing Manager ° d ONLN dP Mr Y˛ ( uêcontinues to evolve. Many ° d ONLN dj Y < e ¶ ( Å Zapplications currently ° d ONLN dÅ Y ¶ e˛ )jBcheck for wDev = 3 to determine whether or not to send PostScript. ° d ONLN dƒ e < qG ( ç Z1Although the Apple LaserWriter driver has a wDev ° d ONLN dı eG q˛ ( çe%of 3, third-party printer drivers for ° d ONLN d q < } ” ( ô Z!PostScript devices do not, so if ° d ONLN d< q ” }˛ )ó=your application determines whether or not to send PostScript ° d ONLN dz } < âK ( • Z6based on wDev alone, your application may incorrectly ° d ONLN d∞ }K Ⲡ( •i#print with QuickDraw on third-party ° d ONLN d‘ â < ï r ( ± Z PostScript ° d ONLN dfl â r ï˛ )6Ldevices. A second problem concerns spoolers and spool files. If a spooler is ° d ONLN d, ï < °õ ( Ω ZIinstalled between an application and the printer driver that is going to ° d ONLN du ïõ °˛ ( Ωπdo the printing, the ° d ONLN dä ° < ≠À ( … ZUapplication receives the wDev ID of the spooler instead of the target driver. If the ° d ONLN dfl °À ≠˛ ( …È application ° d ONLN dÎ ≠ < π% ( ’ Z0makes assumptions based on this ID, it probably ° d ONLN d ≠% π˛ )È.gets unexpected results. In the future, it may ° d ONLN dJ π < ≈ Ÿ ( · Z#also be possible to redirect spool ° d ONLN dm π Ÿ ≈˛ )ù?files. This means that a file that was originally spooled for a ° d ONLN d≠ ≈ < — Ù ( Ì Z(PostScript printer may be redirected to ° d ONLN d’ ≈ Ù —˛ )∏7a QuickDraw device. If the spool file contains only the ° d ONLN d
— < › ( ˘ Z.PostScript representation of the document, it ° d ONLN d; — ›˛ )’0will be useless to the QuickDraw device. Despite ° d ONLN dl › < ÈÁ ( ZTthese strong warnings, some developers are convinced they need the wDev values, and ° d ONLN d¿ ›Á È˛ (there ° d ONLN dΔ È < ı ( Z]may be some vertical applications where they’re needed. For those cases, here is the current ° d ONLN d# È ı˛ (list ° d ONLN d( ı < Ú ( Z&of wDev IDs for Apple printer drivers: ,
Courier
° d ONLN dO
< ˇ *' Device wDev (Hi Byte) ° d ONLN dw <" √ *
ImageWriter I/II: 1 ° d ONLN dì! <, å *
LaserWriter, ° d ONLN d§+ <6 • *
LaserWriter Plus, ° d ONLN d∫5 <@ • *
LaserWriter IINT, ° d ONLN d–? <J √ *
LaserWriter IINTX: 3 ° d ONLN dÏI <T √ *
LaserWriter IISC: 4 ° d ONLN dS <^ √ *
ImageWriter LQ: 5 ° d ONLN d$] <h √ *
AppleFax Modem: 10
° d ONLN d@s <÷ *WDTS does not support the use of these constants. They are definitely subject to change.
° d ONLN dòó <¶‡ *'=Determining if a printer driver accepts Color QuickDraw calls
° d ONLN d÷¶ <≤ ™ * Date Written: 11/21/90 ° d ONLN dÓ≤ <æ • * Last reviewed: 8/1/92 ° d ONLN d <÷¿ *PHow do you find out if a printer driver accepts Macintosh Color QuickDraw calls? ° d ONLN dV÷ <‚ N * ___ ° d ONLN dZÓ <˙ Í *'Check to see if the printer driver has ° d ONLN dÅÓ Í˙˛ )Æ<returned a color grafPort to your application after the call ° d ONLN dæ˙ <G (" Z8to PrOpenDoc (that is, the port that PrOpenDoc returns). ° d ONLN d˜ < } *
To determine ° d ONLN d } ˛ )APif the grafPort is color, you need to check to see if rowBytes from the grafPort ° d ONLN d U <*} (F ZDare less than 0. The following code fragment demonstrates this idea:
° d ONLN d ö6 <A≥ *K(* This function determines if the port passed to it is a color port. If *) ° d ONLN d Ê@ <K æ *
(* so, it returns TRUE. *) ° d ONLN d
^ <iE * 5FUNCTION ColorPort(portInQuestion: GrafPtr): BOOLEAN; ° d ONLN d
7h <s U *
BEGIN ° d ONLN d
=r <}1 *
1 IF portInQuestion^.portBits.rowBytes < 0 THEN ° d ONLN d
o| <á π *
ColorPort := TRUE ° d ONLN d
âÜ <ë d *
ELSE ¡ X¡
*) PR 510 - Printer Driver Q&As (÷˙11 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇˆ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘ ,
Courier
° d ONLN d ( ü * ColorPort := FALSE; ° d ONLN d ' 2 , *
END;
° d ONLN d ! I X^ *&.Printing in mixed Macintosh System 6/7 network
° d ONLN dC? K z * Date Written: 4/8/91 ° d ONLN dYK W á * Last reviewed: 6/14/93 ° d ONLN dqc oí *MWith the System 7.0 version of the LaserWriter driver, when the user selects ° d ONLN dæcío⁄ (ã∞
Envelope from ° d ONLN dÃo {ø (ó 6Zthe Page Setup dialog, the page size returned by the driver is still a standard page: 8.5 ° d ONLN d&oø{⁄ (ó›x 11. ° d ONLN d,{ á8 (£ 68How do you recommend that applications display the page ° d ONLN dd{8á⁄ (£V size when the user has chosen a ° d ONLN dÑá ì Ö (Ø 6nonstandard page size? ° d ONLN dõì ü * * ___ ° d ONLN dü´ ∑ ß *We recommend that you have ° d ONLN d∫´ ß∑⁄ )è>the page preview show a full page instead of an envelope-sized ° d ONLN d˘∑ √! (fl 65page. The LaserWriter driver supports a large number ° d ONLN d.∑!√⁄ (fl?&of PostScript devices, and it can’t be ° d ONLN dU√ œû (Î 6Wsure whether the envelope will be fed on the right, left, or center of the paper tray. ° d ONLN d¨√ûœ⁄ (κ If you show ° d ONLN d∏œ € Y (˜ 6the full page, ° d ONLN d«œ Y€⁄ )ASa user can print on any device by putting the text in the correct location for that ° d ONLN d€ Á : ( 6device. ° d ONLN d#Û ˇO *?Manufacturers of PostScript printers can add custom page sizes ° d ONLN dbÛOˇ⁄ (m to the LaserWriter driver. If ° d ONLN dġ / (' 6they ° d ONLN dÖˇ / ⁄ )Ydo, the representation on the screen will be whatever they decide to define. Applications ° d ONLN dfl Ä (3 6Oshould not try to interpret custom page sizes. If your application ignores the ° d ONLN d. Ä⁄ (3ûresults returned by ° d ONLN dB # (? 63the driver, you risk incompatibility down the road.
° d ONLN dv; JÜ *'3Asynchronous LaserWriter driver no longer supported
° d ONLN d™J V Ä * Date Written: 9/24/91 ° d ONLN d¡V b Å * Last reviewed: 8/1/92 ° d ONLN dÿn z ? *What is ° d ONLN d‡n ?z⁄ )'Tcausing incorrect characters to be printed on the asynchronous LaserWriter driver we ° d ONLN d 5z Üz (¢ 6Ilicensed from Apple for use with a non-Apple PostScript-equipped printer? ° d ONLN d Ü í * * ___ ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 5 È ( Q Z%The printing of incorrect characters ° d ONLN d % ) È 5˛ )≠7is probably due to an incompatibility between the async ° d ONLN d ] 5 < A] ( ] Z?driver and the version of PostScript being used in the printer. ° d ONLN d ù M < Y ô *The reason for the ° d ONLN d ∞ M ô Y˛ )]Iincompatibility is that the driver is no longer supported and hasn’t been ° d ONLN d ˙ Y < e √ ( Å Z revised for quite some time. ° d ONLN d Y √ e˛ )á?The driver was originally developed outside of Apple, and Apple ° d ONLN dW e < q À ( ç Z!licensed the driver for its use. ° d ONLN dx e À q˛ )è<The company subsequently went out of business and the driver ° d ONLN dµ q < } ¥ ( ô Zhasn’t been revved since. ° d ONLN dœ â < ï ‡ *!PostScript and Apple’s AppleTalk ° d ONLN d â ‡ ï˛ )§9LaserWriter drivers have been updated and changed quite a ° d ONLN d* ï < °æ ( Ω ZRbit since then, which is why the characters print correctly when using AppleTalk, ° d ONLN d| ïæ °˛ ( Ω‹ but not when ° d ONLN dâ ° < ≠& ( … Z.printing asynchronously. The old async driver ° d ONLN d∑ °& ≠˛ )Í'just doesn’t know how to handle the new ° d ONLN dfl ≠ < π_ ( ’ Z>PostScript versions and therefore prints “garbage” characters. ° d ONLN d ≈ < —g *?The SL Laser II driver is no longer supported by Apple, and at ° d ONLN d] ≈g —˛ ( ÌÖ this time Apple has no plans to ° d ONLN d} — < ›I ( ˘ Z9update this driver or write a new one. Since things work ° d ONLN d∂ —I ›˛ ( ˘g$correctly with AppleTalk, you should ° d ONLN d€ › < È# ( Z)confine usage to AppleTalk when printing ° d ONLN d ›# È˛ )Á)PostScript to the LaserWriter. If this is ° d ONLN d. È < ıê ( ZCunacceptable, you might check around with different clearinghouses ° d ONLN dq Èê ı˛ (Æto see if a third-party ° d ONLN dâ ı <‰ ( ZXdeveloper has a compatible, up-to-date asynchronous LaserWriter driver that you can use.
° d ONLN d‚ <(Ë *'=Use LaserWriter driver srcCopy instead of srcOr transfer mode
° d ONLN d ( <4 û * Date Written: 5/1/91 ° d ONLN d64 <@ ´ * Last reviewed: 6/14/93 ° d ONLN dNL <Xn *=I’m creating PICTs that are comprised of many lines drawn in ° d ONLN dãLnX˛ (tåsrcOr mode. When using the ° d ONLN d¶X <d~ (Ä ZDLaserWriter 6.x or 7.x driver with the Color/Grayscale radio button ° d ONLN dÍX~d˛ (Äú selected, some lines fail to ° d ONLN dd <p » (å Z print. Why is this happening? ° d ONLN d%p <| N * ___ ° d ONLN d)à <î *SThe problem is a bug in the LaserWriter driver. Sometimes, when using a CGrafPort, ° d ONLN d|àî˛ (∞the ° d ONLN dÄî <† (º ZNdriver doesn’t reproduce lines drawn in srcOr mode. (A CGrafPort is used when ° d ONLN dŒî†˛ (ºthe ° d ONLN d“† <¨- (» Z3Color/Grayscale print option is selected; in Black ° d ONLN d†-¨˛ )Ò)& White print mode, a regular grafPort is ° d ONLN d/¨ <∏ ¡ (‘ Zused.) A workaround is to ° d ONLN dI¨ ¡∏˛ )Ö;use srcCopy instead of srcOr when drawing QuickDraw objects ° d ONLN dÖ∏ <ƒ ô (‡ Zwithin your PICTs.
° d ONLN dò‹ <Ϊ *'7Save and restore long word if using $948 under System 7
° d ONLN d–Î <˜ § * Date Written: 6/11/91 ° d ONLN dÁ˜ < • * Last reviewed: 8/1/92 ° d ONLN d˛ <œ *UUnless my Macintosh application restores the contents of the long word at $948 after ° d ONLN dSœ˛ (7Ì
using that ° d ONLN d^ <' ñ (C Zspace for globals, ° d ONLN dq ñ'˛ )ZHthe Finder draws icons incorrectly and my third-party LaserWriter driver ° d ONLN d∫' <3R (O Z7crashes. Is somebody now using $948 for other purposes? ° d ONLN dÚ3 <? N * ___ ° d ONLN dˆK <W≈ *RThis is a known System 7 icon drawing bug, and also a bug with the printer driver ° d ONLN d HK≈W˛ (s„ that you are ° d ONLN d UW <c Z ( Zusing. ° d ONLN d \o <{æ *VThe icon drawing utilities are trying to determine if a print page is currently open, ° d ONLN d ≤oæ{˛ (ó‹
by looking at ° d ONLN d ¿{ <á› (£ Z]that variable ($948 is part of printvars). This turns out not to be such a good idea, and it ° d ONLN d
{›á˛ (£˚will be ° d ONLN d
%á <ì (Ø Z1fixed in the next release of the system software. ¡ X¡
*' PR 510 - Printer Driver Q&As (÷˙13 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇ. ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5 á *$The printer driver bug ° d ONLN d ) á 5⁄ )oFthat you are experiencing is that every printer driver must return the ° d ONLN d ^ 5 A√ ( ] 6\variable at $948 to -1 when they are done printing. Also, while printing, the driver should ° d ONLN d ∫ 5√ A⁄ ( ]·set it ° d ONLN d ¡ A M C ( i 6 to <> -1.
° d ONLN d À e tº *';Update Backgrounder if using LaserWriter 7.0 under System 6
° d ONLN d t Ä Ä * Date Written: 7/10/91 ° d ONLN d Ä å Å * Last reviewed: 8/1/92 ° d ONLN d5 ò § *3When we use the LaserWriter driver 7.0 with System ° d ONLN dh ò §⁄ )ˇ&6.0, the Chooser’s Background Printing ° d ONLN dè § ∞â ( à 6KOn button is always dimmed. Is there any way to enable background printing? ° d ONLN d€ ∞ º * * ___ ° d ONLN dfl » ‘ 9 *To get ° d ONLN dÊ » 9 ‘⁄ )!Sthe LaserWriter 7.0 driver to work with System 6.0.x, update your Backgrounder file ° d ONLN d: ‘ ‡Ä ( ¸ 6Nwith the version on the Printing Tools disk that’s used to install System 7.0. ° d ONLN dâ Ï ¯¬ *WIn short, to use the 7.0 LaserWriter Driver, 7.0 PrintMonitor, and System 6.0.x, place ° d ONLN d‡ Ϭ ¯⁄ (‡these ° d ONLN dÊ ¯ I ( 6 files from ° d ONLN dÒ ¯ I⁄ )1Sthe System 7.0 Printing Tools installation disks into your System Folder. All three ° d ONLN dE \ (, 6
must be used ° d ONLN dR \⁄ )DOtogether for printing to work correctly. After you’ve placed these files in the ° d ONLN d¢ Ø (8 6SSystem Folder, you should find the Background Printing option enabled for your use. ° d ONLN dˆ( 4z *EThere are no known incompatibilities with the 7.0 drivers and System ° d ONLN d;(z4⁄ (Pò6.0.x, so everyone ° d ONLN dN4 @ € (\ 6+should use the latest drivers, even with a ° d ONLN dy4 €@⁄ )√5mixed environment. This will also get rid of “printer ° d ONLN dØ@ Lò (h 6Pwars” that occur when users use more than one version of the LaserWriter driver ° d ONLN dˇ@òL⁄ (h∂to print to the ° d ONLN dL Xk (t 6Lsame printer. (The printer must be reinitialized if the current user uses a ° d ONLN d[LkX⁄ (tâdifferent version of the ° d ONLN dtX d „ (Ä 6,driver than that used by the previous user.)
° d ONLN d°| ãL *',LaserPrep 7.0 file & AppleShare Print Server
° d ONLN dŒã ó Ä * Date Written: 7/15/91 ° d ONLN dÂó £ Å * Last reviewed: 8/1/92 ° d ONLN d¸Ø ª v *The LaserPrep 7.0 ° d ONLN dØ vª⁄ )^Efile is included on the System 7 Printing disk and the System 7 Group ° d ONLN dTª «∫ („ 6SUpdate CD for upgrading the AppleShare Print Server to support the LaserWriter 7.0 ° d ONLN dߪ∫«⁄ („ÿdriver. ° d ONLN dØ« ”Ø (Ô 6XThe AppleShare Print Server has its own LaserWriter driver built in and all it needs to ° d ONLN d«Ø”⁄ (ÔÕ
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ,Ö ( H Z/LaserWriter 7.0 driver and LaserPrep dictionary
° d ONLN d 0 , < 8 § * Date Written: 8/29/91 ° d ONLN d G 8 < D ´ * Last reviewed: 6/14/93 ° d ONLN d _ P < \ */In the old LaserWriter drivers it was possible ° d ONLN d é P \˛ )‡/to create a PostScript file with or without the ° d ONLN d æ \ < h ( Ñ Z-LaserPrep dictionary (“f” or “k” key). Is it ° d ONLN d Î \ h˛ )”2possible to generate a file without the dictionary ° d ONLN d h < t ‘ ( ê Z with the LaserWriter 7.0 driver? ° d ONLN d? t < Ä N * ___ ° d ONLN dC å < ò$ *2In 7.0 printing, a LaserPrep dictionary is always ° d ONLN du å$ ò˛ )Ë.sent with a print job. This is done to prevent ° d ONLN d§ ò < § ( ¿ Z-constant reinitialization of the LaserWriter ° d ONLN d— ò §˛ )»5by conflicting printer drivers. You cannot prevent it ° d ONLN d § < ∞ ˆ ( à Z%from being sent. Fortunately the 7.0 ° d ONLN d, § ˆ ∞˛ )∫3version of the LaserPrep dictionary is much smaller ° d ONLN d` ∞ < º Û ( ÿ Z'(≈40K total) than its 6.x predecessors.
° d ONLN dà ‘ < „„ *'<LaserWriter ignores ForeColor while filling smoothed polygon
you’ll get ° d ONLN dK£ <Ø^ (À Z<the “jaggies.” Second, you’ll probably want to increase the ° d ONLN dá£^Ø˛ (À|"printer port’s resolution from its ° d ONLN d™Ø <ª (◊ Z1default of 72 dpi for better results. A value of ° d ONLN d€Øª˛ )Ÿ0288 dpi works nicely since it’s an even multiple ° d ONLN d ª <« („ Z)of QuickDraw’s native 72-dpi resolution. ° d ONLN d5ª«˛ )Δ2Also, make sure that the GWorld you create has the ° d ONLN dh« <”ò (Ô ZGsame bounds as the printer port’s rPage rectangle to avoid unnecessary ° d ONLN dØ«ò”˛ (Ô∂scaling and clipping. ° d ONLN d≈” <flT (˚ Z:After you’ve done all that, draw into it and CopyBits the ° d ONLN dˇ”Tfl˛ (˚r$result to the printer port. The nice ° d ONLN d$fl <Î ˙ ( Z(thing about doing everything off-screen ° d ONLN dLfl ˙Î˙ )æ6first is that then you can use some of the non-printer ° d ONLN dÇfl˙β (- ° d ONLN dÉÎ <˜p ( ZBfriendly transfer modes like blend or dithered. Also, you can use ° d ONLN d≈Îp˜˛ (éForeColor/BackColor and get ° d ONLN d·˜ < ≠ ( Zthe right thing this way. ° d ONLN d˚ <p *EIf you don’t want to use this method for all printers, (since it can ° d ONLN d @p˛ (7ébe quite a memory hog), you ° d ONLN d \ <'º (C ZPcan check for the LaserWriter driver and use this method in just that case. For ° d ONLN d ¨º'˛ (C⁄other drivers, ° d ONLN d ª' <3 ” (O Z you should just print as normal. ° d ONLN d ‹? <K – *So, what do you need to do ° d ONLN d ˜? –K˛ )î>all this? Well, to set the resolution of the printer port, use ° d ONLN d
6K <W ∏ (s ZPrGeneral as described in ° d ONLN d
PK ∏W )|Inside Macintosh ° d ONLN d
`K WS )Q Volume V and ° d ONLN d
nKSWx )Jdevelop ° d ONLN d
uKxWã )% #3. ° d ONLN d
zc <oë (ã ZGTo determine whether you have the LaserWriter driver or not, check the ° d ONLN d
¡cëo˛ (ãØhigh byte of the wDev ° d ONLN d
◊o <{ Ë (ó Z!field in your print handle. This ° d ONLN d
¯o Ë{˛ )¨1is described in the Tech Note “Optimizing For The ° d ONLN d *{ <á> (£ Z1LaserWriter—Techniques.” While this method might ° d ONLN d [{>Რ(£\'break some day, it’s currently the best ¡ X¡
(÷ Z PR 510 - Printer Driver Q&As (÷˙15 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )J *;way to determine which driver you’re using, and Apple will ° d ONLN d ; J )⁄ ( Ehhave to let developers know ° d ONLN d W ) 5 q ( Q 6before we break it. ° d ONLN d k A M c *If the high byte ° d ONLN d | A c M⁄ )KNof the wDev is 3, then you either have the LaserWriter driver or a third-party ° d ONLN d À M Yb ( u 6Adriver impersonating the LaserWriter. Some PostScript drivers do ° d ONLN d Mb Y⁄ ( uÄthat because many apps ° d ONLN d# Y e H ( Å 6 assume a ° d ONLN d, Y H e⁄ )0OwDev of 3 means a PostScript printer, and anything else doesn’t. By acting like ° d ONLN d| e q ° ( ç 6 Apple’s LaserWriter driver, ° d ONLN dò e ° q⁄ )âAthey get preferential treatment from apps that “special case” for ° d ONLN d⁄ q } ( ô 6:PostScript. That’s not really a problem in this situation.
° d ONLN d ï §ø *'<LaserWriter driver PostScript error strings & document names
° d ONLN dR § ∞ Ü * Date Written: 12/11/91 ° d ONLN dj ∞ º Å * Last reviewed: 8/1/92 ° d ONLN dÅ » ‘w *LI discovered an interesting bug in the Macintosh LaserWriter driver. If the ° d ONLN dÕ »w ‘⁄ ( ïword “timeout” is in ° d ONLN d‚ ‘ ‡√ ( ¸ 6Tthe name of a document, the LaserWriter driver will give a timeout error -8132. Are ° d ONLN d6 ‘√ ‡⁄ ( ¸·there ° d ONLN d< ‡ Ï } ( 6similar magic words? ° d ONLN dQ Ï ¯ * * ___ ° d ONLN dU ö *NPostScript error messages are sent from the LaserWriter to the driver as text ° d ONLN d£ö⁄ (,∏ streams. The ° d ONLN d∞ h (8 6Idriver must check these strings to see if they contain an error message. ° d ONLN d˘h ⁄ (8ÜIf a document is named ° d ONLN d ( Ë (D 6+something that contains the same string as ° d ONLN d; Ë(⁄ )–0a PostScript error message, the driver may think ° d ONLN dl( 4Æ (P 6Nthere’s an error when the printer sends the “status: printing document XXXXX” ° d ONLN d∫(Æ4⁄ (PÃmessage. ° d ONLN d√4 @ (\ 62Other strings cause similar problems; one of them ° d ONLN dı4@⁄ )Ì-is “printer out of paper.” If you want to see ° d ONLN d#@ L ∏ (h 6%the rest of the strings, take a look ° d ONLN dH@ ∏L⁄ )†;at the LaserWriter printer driver resource type 'PREC' ID = ° d ONLN dÑL X . (t 6109.
° d ONLN dâp z *'2Personal LaserWriter NTR has longer product string
° d ONLN dº ã Ä * Date Written: 3/17/92 ° d ONLN d”ã ó á * Last reviewed: 6/14/93 ° d ONLN dΣ Ø *The following line of ° d ONLN d£ Ø⁄ )gEmy PostScript code causes the Personal LaserWriter NTR to gag, but it ° d ONLN dGØ ªG (◊ 6?has worked with all other Apple LaserWriter printers up to now: ,
Courier
° d ONLN dá« “û *N statusdict/product get str cvs show % Gets & prints the name of the printer
° d ONLN d÷› È Ö *where str is defined as:
° d ONLN dÔı | * /str 20 string def
° d ONLN dˇ * * ___ ° d ONLN d # *,The product name stored for this printer is ° d ONLN d4#⁄ )Í'(LaserWriter Personal NTR) or (Personal ° d ONLN d\# / v (K 6LaserWriter NTR), ° d ONLN dn# v/⁄ )^Idepending on whether you’re using statusdict or systemdict, respectively. ° d ONLN d∏/ ; … (W 6(In either case, the product’s length is ° d ONLN d‡/ …;⁄ )±924 characters. Since you’re only allocating 20 characters ° d ONLN d; G≥ (c 6Xfor the 2nd string you use with cvs, you’re getting a rangecheck error. Changing str to:
° d ONLN dsS ^ | * /str 24 string def
° d ONLN dài u. *3fixes the problem. You may want to make the string ° d ONLN dªi.u⁄ (ëL!even larger than 24 characters to ° d ONLN d›u Å (ù 6/accommodate longer product names in the future. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < )Í ( E ZUAssumptions about the length of PostScript product strings are a common problem with ° d ONLN d U Í )˛ ( Enew ° d ONLN d Y ) < 5à ( Q ZCprinters (having more verbose names). In fact, you should have the ° d ONLN d ú )à 5˛ ( Q¶same trouble if you run ° d ONLN d ¥ 5 < A‚ ( ] ZWyour original PostScript on the Personal LaserWriter NT, which has a 23 character name.
° d ONLN d Y < h] *'*LaserWriter II SC fonts and 4x bitmap size
° d ONLN d7 h < t ™ * Date Written: 11/17/89 ° d ONLN dO t < Ä ´ * Last reviewed: 6/14/93 ° d ONLN dg å < ò œ *Why do I need to have four ° d ONLN dÇ å œ ò˛ )ì;times the bitmap size of the font I want to print in on the ° d ONLN dæ ò < § ñ ( ¿ ZLaserWriter II SC? ° d ONLN d— § < ∞ N * ___ ° d ONLN d’ º < » Ç *LaserWriter II ° d ONLN d‰ º Ç »˛ )FOSC fonts are four times the point size of the associated Macintosh screen font. ° d ONLN d4 » < ‘ ( Z+The pixels on the screen are four times as ° d ONLN d_ » ‘˛ )Δ7far apart (center to center) as the dots printed by the ° d ONLN dó ‘ < ‡· ( ¸ ZXLaserWriter SC. When the bitmaps for one of the printer fonts is printed, the result is ° d ONLN dÔ ‘· ‡˛ ( ¸ˇa font ° d ONLN dˆ ‡ < Ï ( Z2with a resolution four times greater than that of ° d ONLN d( ‡ Ï˛ )‡2the font displayed, but at a size identical to the ° d ONLN d[ Ï < ¯ ƒ ( Z font displayed on the screen.
° d ONLN dy < J *''Font families shipped with LaserWriters
° d ONLN d° <+ ™ * Date Written: 11/17/89 ° d ONLN dπ+ <7 • * Last reviewed: 8/1/92 ° d ONLN d–C <O ä *What fonts and ° d ONLN dflC äO∞ )N;sizes are shipped with the LaserWriter Plus, LaserWriter II
° d ONLN dC∞OΩ (kŒNT
° d ONLN d CΩO˛ )
, LaserWriter ° d ONLN d*O <[ D (w ZII
° d ONLN d,O D[ X )NTX
° d ONLN d/O X[ ¬ ), and LaserWriter SC? ° d ONLN dE[ <g N (É Z___ ° d ONLN dIs < Ô *$The LaserWriter Plus, LaserWriter II
° d ONLN dms Ô ¸ )≥NT
° d ONLN dos ¸ )
, ° d ONLN dqs_ )and LaserWriter II
° d ONLN dÉs_s )[NTX
° d ONLN dÜss˛ ) , shipped with a total of 11 ° d ONLN d£ <ã
(ß Z-font families with the sizes indicated below: ° d ONLN d—ó <£N *8Times, Helvetica, Courier, Symbol: 9, 10, 12, 14, 18, 24 ° d ONLN d
Ø <ª *(Palatino, Helvetica Narrow, ITC Bookman, ° d ONLN d3ª <« * *ITC Avant Garde Gothic, ITC Zapf Chancery, ° d ONLN d^« <”s * <ITC Zapf Dingbats, New Century Schoolbook 10, 12, 14, 18, 24 ° d ONLN dõfl <Îı *]A total of four font families are shipped with the SC: Courier, Symbol, Times, and Helvetica ° d ONLN d¯flıβ (in ° d ONLN d˚Î <˜P ( Z;the following sizes: 9, 10, 12, 14, 18, 24, 36, 48, 56, 72, ° d ONLN d7˜ < L * 96.
° d ONLN d; <*ÿ *';Disable Graphics Smoothing for printing large bitmap images
° d ONLN dw* <6 û * Date Written: 5/3/89 ° d ONLN dç6 <B ´ * Last reviewed: 6/14/93 ° d ONLN d•N <ZÈ *TWhen printing large (possibly scanned) Macintosh bitmap images, the page is printed ° d ONLN d˘NÈZ˛ (vwith ° d ONLN d˛Z <fL (Ç Z8small lines running horizontally through the image. Why? ° d ONLN d7f <r N * ___ ° d ONLN d;~ <äÊ *VIn System 6.0 the QuickDraw DrawPicture call was revised to fix some problems. One of ° d ONLN dë~Êä˛ (¶these ° d ONLN dóä <ñó (≤ ZGproblems concerned large bitmaps. To help solve the problem of bitmaps ° d ONLN dfiäóñ˛ (≤µthat were too large to ¡ X¡
(÷ Z PR 510 - Printer Driver Q&As (÷˙17 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇr ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )Ö *Gbe printed, DrawPicture was modified to “band” the CopyBits request if ° d ONLN d G Ö )⁄ ( E£it was too large. ° d ONLN d Y ) 5
( Q 64Banding is the process of converting a large bitmap ° d ONLN d ç )
° d ONLN d‡ ï §q *'0Difference between LaserWriter 7.0 and 7.1 Namer
° d ONLN d § ∞ z * Date Written: 3/3/92 ° d ONLN d' ∞ º Å * Last reviewed: 8/1/92 ° d ONLN d> » ‘ *-Apple Software Licensing’s “Exhibit C” lists ° d ONLN dk » ‘⁄ )Ô'localized Namer 7.0 versions in several ° d ONLN dì ‘ ‡Δ ( ¸ 6\languages, and mentions that these localized versions of the Namer are available in version ° d ONLN dÔ ‘Δ ‡⁄ ( ¸‰7.1. ° d ONLN dÙ ‡ Ï( ( 68What is the difference in the Namer between 7.0 and 7.1? ° d ONLN d- Ï ¯ * * ___ ° d ONLN d1 G * The main ° d ONLN d: G⁄ )/Tdifference between the LaserWriter utility 7.0 and 7.1 is that part of the Namer has ° d ONLN dè ; (8 6@been integrated into the 7.1 version of the software. Until the ° d ONLN dœ; ⁄ (8Y LaserWriter utility 7.1 was made ° d ONLN d ( í (D 6available, the Namer was ° d ONLN d í(⁄ )zDa stand-alone application. However, the LaserWriter utility does not ° d ONLN dN( 4 ' (P 6do ° d ONLN dQ( '4⁄ )Severything the Namer does. For example, the Namer renames AppleTalked ImageWriters, ° d ONLN d•4 @î (\ 6Sbut the LaserWriter utility doesn’t. For all your printer configuration needs, you ° d ONLN d¯4î@⁄ (\≤should use the ° d ONLN d@ L ú (h 6 7.1 version of the software.
° d ONLN d$d sé *'6ImageWriter and printing multiple copies in draft mode
° d ONLN d[s z * Date Written: 1/6/92 ° d ONLN dq ã á * Last reviewed: 6/14/93 ° d ONLN dâó £ - *Our ° d ONLN dçó -£⁄ )Yapplication can’t print multiple copies on the ImageWriter in Draft mode. If we type in 3 ° d ONLN dÁ£ Ø ≥ (À 6!copies in the ImageWriter driver ° d ONLN d£ ≥Ø⁄ )õ:dialog box in Draft mode, we only get one copy. Everything ° d ONLN dCØ ª{ (◊ 6Mprints fine in Best or Faster modes. Is this a bug in the ImageWriter driver? ° d ONLN dëª « * * ___ ° d ONLN dï” flà *^Although it seems like this must be a bug in the ImageWriter driver, it’s not. In Draft mode, ° d ONLN dÛ”Ãfl⁄ (˚Íthe ° d ONLN d˜fl Î+ ( 68application that’s printing must make sure the required ° d ONLN d/fl+Î⁄ (I!number of pages are printed. This ° d ONLN dQÎ ˜q ( 6Jinvolves cycling through the app’s print loop for each copy to be printed. ° d ONLN dú à *]In Draft mode on an ImageWriter, nothing is spooled to disk; the data is immediately sent to ° d ONLN d˘Ã⁄ (+Íthe ° d ONLN d˝ è (7 6Rprinter. Therefore, the data is no longer available once it’s sent to the printer ° d ONLN d Oè⁄ (7≠(and there’s no ° d ONLN d _ ' @ (C 6way for ° d ONLN d g @'⁄ )(Vthe print driver to resend it for multiple copies). When the ImageWriter spool-prints, ° d ONLN d æ' 3` (O 6Ithe file that’s created is printed the required number of times for you. ° d ONLN d
'`3⁄ (O~Therefore, your app only ° d ONLN d
3 ?8 ([ 6<needs to handle multiple copies when printing in Draft mode. ° d ONLN d
]K W ¥ * Here’s what your app should do: ° d ONLN d
}c o ≥ *!1. Validate the print record and ° d ONLN d
ûc ≥o⁄ )õ:present the job dialog. This allows the user to choose how ° d ONLN d
Ÿo {y (ó 6Nmany copies to print and allows the printer driver to adjust the print record ° d ONLN d 'oy{⁄ (óóto reflect how many ° d ONLN d ;{ á ∂ (£ 6!copies your program has to print. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < )º ( E ZR2. Get the number of copies that you’re expected to handle from the print record. ° d ONLN d R º )˛ ( E⁄In the case of ° d ONLN d a ) < 5 ( Q Z_spool printing, this number will be set to 1 (since the multiple copies are handled for you by ° d ONLN d ¿ ) 5˛ ( Qthe ° d ONLN d ƒ 5 < A… ( ] ZWprinter driver). In any case, the following Pascal code will give you the correct info. ,
Courier
° d ONLN d M < Xê *D numCopies:= printHdl^^.prJob.iCopies; (* From IM 2, pg. 151. *)
° d ONLN da c < oË *P3. For each copy in numCopies, loop through the PrOpenDoc/PrCloseDoc section of ° d ONLN d± cË o˛ ( ãyour ° d ONLN d∂ o < { V ( ó Zcode. ° d ONLN dº á < ì§ *GThis method is demonstrated in the code for the Macintosh Tech Note “A ° d ONLN d á§ ì˛ ( جPrinting Loop that ° d ONLN d ì < ü ( ª Z,Cares…,” which describes a model print loop.
° d ONLN dC ∑ < Δ ˚ *'Dogcow logo is trademarked
° d ONLN d^ Δ < “ § * Date Written: 9/10/92 ° d ONLN du “ < fi ´ * Last reviewed: 6/14/93 ° d ONLN dç Í < ˆñ *HWe would like to use the “dogcow” icon in our Page Setup dialog. Is the ° d ONLN d’ Íñ ˆ˛ (¥dogcow trademarked, ° d ONLN dÈ ˆ <j ( ZBand are there any restrictions on using this icon in our software? ° d ONLN d, < N * ___ ° d ONLN d0 <&• *LYes, the dogcow logo (along with its call, “Moof!”) is a trademark of Apple ° d ONLN d|•&˛ (B√and is proprietary. ° d ONLN dê& <2 ° (N ZThe dogcow appears ° d ONLN d£& °2 ⁄ )e on Apple’s ° d ONLN dÆ& ⁄2? )9Developer CD Series ° d ONLN d¡&?2˛ )e( disc and in other material. Apple has a ° d ONLN dÍ2 <> ∏ (Z Zpending U.S. registration ° d ONLN d2 ∏>˛ )|Fon it. Accordingly, it’s not available to third-party developers as an ° d ONLN dK> <J ô (f Zicon or file symbol.
° d ONLN d`b <qr *'.“Printer driver is MultiFinder compatible” bit
° d ONLN dèq <} § * Date Written: 7/29/92 ° d ONLN d¶} <â ´ * Last reviewed: 6/14/93 ° d ONLN dæï <°À *VCould you tell me what the “printer driver is MultiFinder compatible” bit is used for? ° d ONLN d° <≠ N * ___ ° d ONLN dπ <≈ */The “printer driver is MultiFinder compatible” ° d ONLN dHπ ≈˛ )‚/bit provides two features. First, it allows the ° d ONLN dx≈ <— _ (Ì Zprinter ° d ONLN dÄ≈ _—˛ )#Sdriver resource file to be opened by multiple clients. This was obviously needed to ° d ONLN d‘— <› Õ (˘ Z support multiple applications ° d ONLN dÚ— Õ›˛ )ë<printing simultaneously under MultiFinder. The other feature ° d ONLN d/› <ÈÀ ( ZRprovided by the flag is the loading of PDEFs into the system heap rather than the ° d ONLN dÅ›ÀÈ˛ (È application ° d ONLN dçÈ <ı ( Z/heap (which is where they go under the Finder). ° d ONLN dΩ <
Ï *YThe MultiFinder-compatible bit has a major limitation: If your driver has this flag set, ° d ONLN dÏ
˛ ()
you ° d ONLN d
<Ã (5 ZParen’t allowed to add or resize resources, or do anything else that would cause ° d ONLN dj
Ã˙ (5Íthe RAM ° d ONLN dq
˙˛ ).- ° d ONLN dr <% (A Z*resident resource map to change. Although ° d ONLN dú%˛ )Ÿ/MultiFinder lets multiple applications open the ° d ONLN dÃ% <1 õ (M Zprinter resource file ° d ONLN d‚% õ1˛ )_Jat the same time, it has no control over the resource map that gets loaded ° d ONLN d-1 <=4 (Y Z1by the Resource Manager when the file is opened. ° d ONLN d^14=˛ )¯)Because of this, each client gets its own ° d ONLN dà= <Iè (e ZDpersonal copy of the resource map. When these clients get done with ° d ONLN dÃ=èI˛ (e≠the file, they write the ° d ONLN dÂI <U (q ZEresource map back to the file (via UpdateResFile). Obviously, if the ° d ONLN d *IU˛ (qùresources have changed in ° d ONLN d DU <a (} Z/any way, the last client to call UpdateResFile ° d ONLN d sUa˛ )◊/is the only one whose changes will be recorded. ° d ONLN d £a <m ´ (â ZThis is a “thrill seeker” ° d ONLN d Ωa ´m˛ )oGmethod of handling the printer driver resource files, but since none of ° d ONLN d
m <yï (ï ZKthe Apple printer drivers currently add or resize resources, it made sense. ¡ X¡
*A PR 510 - Printer Driver Q&As (÷˙19 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇB ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d )6 *<So the bottom line here is that if you want your drivers to ° d ONLN d < 6 )⁄ ( ET be compatible under MultiFinder, ° d ONLN d ] ) 5® ( Q 6Uyou’ll have to implement a scheme that doesn’t require adding or resizing resources. ° d ONLN d ≤ )® 5⁄ ( QΔ
It’s OK to ° d ONLN d Ω 5 A¶ ( ] 6Rchange the data in a resource, as long as you don’t change its size. Changing the ° d ONLN d 5¶ A⁄ ( ]ƒ
data won’t ° d ONLN d A M≈ ( i 6]cause changes to the resource map, so each client will still have accurate copies of the map. ° d ONLN dx Y eX *BHere’s what would happen to your printer driver’s resources under ° d ONLN d∫ YX e⁄ ( Åvthe Finder and MultiFinder ° d ONLN d’ e q ‚ ( ç 6+when the MultiFinder-compatible bit is set: ° d ONLN d } âD *9• Under the Finder in system software version 6.0.x: All ° d ONLN d: }D â⁄ ( •b resources are loaded into the ° d ONLN dX â ïo ( ± 6Lapplication heap—regardless of the resource attribute’s bit setting. If the ° d ONLN d§ âo ï⁄ ( ±çresource has the “load ° d ONLN dª ï ° b ( Ω 6into the system ° d ONLN dÀ ï b °⁄ )JRheap” bit set, it will still be loaded into the application heap under the Finder. ° d ONLN d ° ≠ 1 ( … 6This ° d ONLN d# ° 1 ≠⁄ )Smakes sense in the Finder world because the application heap will usually have more ° d ONLN dw ≠ π ö ( ’ 6room than the system heap. ° d ONLN dí ≈ — ı *-• Under MultiFinder in System 6 or System 7: ° d ONLN dø ≈ ı —⁄ )›1All the printer driver’s resources will be loaded ° d ONLN dÒ — ›ø ( ˘ 6]into the system heap. This is true whether the “load into the system heap” bit is set or not. ° d ONLN dO È ıt *GWhy does the resource loading occur this way, even when the resource’s ° d ONLN dñ Èt ı⁄ (í“load into the system ° d ONLN d¨ ı ∂ ( 6[heap” bit is set? Patches to the GetResource trap load all your printer driver’s resources ° d ONLN d ı∂⁄ ( ‘into the ° d ONLN d
X () 6=system heap when the MultiFinder-compatible bit is set under ° d ONLN dMX
⁄ ()vMultiFinder, and into the ° d ONLN dg
N (5 6 application ° d ONLN ds
N⁄ )6Pheap under the Finder (as described above), which is why you can’t override this ° d ONLN dƒ % E (A 6 behavior. ° d ONLN dŒ1 =à *PBy the way, you should be aware of the SetPDiMC MPW tool, which is available on ° d ONLN d 1Ã=⁄ (YÍthe ° d ONLN d"= I { (e 6Developer CD Series ° d ONLN d5= {I¿ )cH disc. It will automatically set the MultiFinder-compatible bit for you ° d ONLN d}=¿I⁄ (efiwhen ° d ONLN dÇI U £ (q 6 you build your printer driver.
° d ONLN d°m || *'6Use FillCRect off-screen, not directly to printer port
° d ONLN dÿ| à Ä * Date Written: 8/25/92 ° d ONLN dÔà î ç * Last reviewed: 11/30/92 ° d ONLN d† ¨Ã *YWe’re having problems with color patterns using the LaserWriter driver version 7.1.2. If ° d ONLN da†Ã¨⁄ (»Íwe ° d ONLN dd¨ ∏æ (‘ 6Ycreate a 'ppat' resource in ResEdit (32 x 32 bits, in this case) and then do a FillCRect ° d ONLN dΩ¨æ∏⁄ (‘‹to the ° d ONLN dƒ∏ ƒ (‡ 68port returned by PrOpenDoc (with color set so that it’s ° d ONLN d¸∏ ƒ⁄ (‡:'a cGrafPort) with the pattern loaded by ° d ONLN d$ƒ –® (Ï 6JGetPixPat, we get a weird pattern. Doing the same to an off-screen GWorld ° d ONLN dnƒ®–⁄ (ÏΔ and using ° d ONLN dx– ‹ H (¯ 6 CopyBits ° d ONLN dÅ– H‹⁄ )0Tto copy to the printer port works fine, if a little slowly. Are we missing something ° d ONLN d÷‹ Ë 1 ( 6here? ° d ONLN d‹Ë Ù * * ___ ° d ONLN d‡ - *:You need to use the FillCRect call off-screen rather than ° d ONLN d - ⁄ ((K&directly into the printer port, for at ° d ONLN d A ˇ (4 61least two reasons. First, the LaserWriter driver ° d ONLN d r ˇ⁄ )Á-doesn’t support filling objects with anything ° d ONLN d † $É (@ 6Lbut black-and-white patterns because it uses the PostScript halftone screen ° d ONLN d ÏÉ$⁄ (@°functions to draw ° d ONLN d ˛$ 0 Ç (L 6patterns. Second, the ° d ONLN d
$ Ç0⁄ )jELaserWriter driver doesn’t understand (or handle) pixPats. Therefore, ° d ONLN d
Z0 < (X 6your only recourse is ° d ONLN d
p0 <⁄ )gBthe one you discovered—to copy to and from GWorlds. Unfortunately, ° d ONLN d
≥< H Ù (d 6,FillCRect doesn’t work with the LaserWriter ° d ONLN d
fl< ÙH⁄ )‹.drivers through version 7.2. After version 7.2 ° d ONLN d H T π (p 6!this probably won’t be a problem.
° d ONLN d 0l {∑ *'9Color/Grayscale button on a non–Color QuickDraw Macintosh
° d ONLN d j{ á Ä * Date Written: 8/31/92 ° d ONLN d Åá ì á * Last reviewed: 6/14/93 ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 5» ( Q ZOThe LaserWriter driver displays the Color/Grayscale option even on a non–Color ° d ONLN d O )» 5˛ ( QÊ QuickDraw ° d ONLN d Y 5 < Ah ( ] Z7Macintosh, which seems odd because the option normally ° d ONLN d ê 5h A˛ ( ]Ü causes the driver to return a ° d ONLN d Æ A < Mø ( i ZHCGrafPort to the calling application, and CGrafPorts are only available ° d ONLN d ˆ Aø M˛ ( i› under Color ° d ONLN d M < Y ( u Z+QuickDraw. What happens if you’re printing ° d ONLN d- M Y˛ )◊/original QuickDraw colors using the LaserWriter ° d ONLN d] Y < eô ( Å ZEdriver on a non–Color QuickDraw system? Does the driver just use the ° d ONLN d¢ Yô e˛ ( Å∑Black & White code ° d ONLN dµ e < q\ ( ç Z=regardless of whether the Color/Grayscale button is selected? ° d ONLN dÛ q < } N * ___ ° d ONLN d˜ â < ï` *>Regardless of whether Color/Grayscale is selected or not, the ° d ONLN d5 â` ï˛ ( ±~!driver returns a grafPort because ° d ONLN dW ï < ° ó ( Ω Zit’s not running on ° d ONLN dk ï ó °˛ )[Ga Color QuickDraw machine. But, if the Color/Grayscale option is chosen ° d ONLN d≥ ° < ≠ ( … Z,on a Macintosh without Color QuickDraw, the ° d ONLN dfl ° ≠˛ )fi.driver doesn’t just use the Black & White code ° d ONLN d ≠ < πd ( ’ ZEto print. Instead, it sends the colors to the printer as best it can ° d ONLN dS ≠d π˛ ( ’Ç without Color QuickDraw. This ° d ONLN dq π < ≈¿ ( · ZTcan result in three different sets of output when printing classic QuickDraw colors: ° d ONLN dΔ — < › ’ * • Black & White button selected ° d ONLN dÊ — ’ ›˛ )ô;(identical output whether the system has Color QuickDraw or ° d ONLN d" › < È O ( Znot) ° d ONLN d' È < ıs * >• Color/Grayscale button selected on Color QuickDraw Macintosh ° d ONLN df ı <â * B• Color/Grayscale button selected on non-Color QuickDraw Macintosh ¡ X¡
(÷ Z PR 510 - Printer Driver Q&As (÷˙21 )
of 21 (Ï ZM.PR.PrtDvr.Q&As ˇb ◊# ˇ ˇˇˇˇ # ◊ † Ç
/ Z Å#
0Ià:µú9 " { ˇˇˇˇˇˇˇˇ # † ƒ ° d
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < ÅS ( õ Z PR 515 - Printing Manager Q&As
° d ONLN d Ä < è s *Printing
° d ONLN d ) õ < ß t * Revised by: ° d ONLN d 5 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d N õ± ߲ ( √œSeptember 1993 ° d ONLN d ] ß < ≥ q ( œ Z Written by: ° d ONLN d i ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d Ç ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d è ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d Æ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ë À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d/ À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dB ◊ < „ u ( ˇ Z
While DSC ° d ONLN dL ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dô „ < Ô q ( Z don’t have ° d ONLN d§ „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dˆ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dK ˚ < (# Z,information migrates into reference manuals. ° d ONLN dx < k *:Q&As are now included with Technical Notes to make access ° d ONLN d≤k ˛ (;â to technical updates easier for ° d ONLN d“ <+. (G Z/you. If you have comments or suggestions about ° d ONLN d .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d,+ <7 \ (S Zknow ° d ONLN d1+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN d{7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN dµO <[ · * New Q&As in this Technical Note: ° d ONLN d÷[ <gG * 5OK to call WaitNextEvent if modal window is frontmost í Xí
° d ONLN d å <õµ *45OK to call WaitNextEvent if modal window is frontmost
° d ONLN dBõ <ß § * Date Written: 1/20/93 ° d ONLN dYß <≥ ´ * Last reviewed: 6/14/93 ° d ONLN dqø <À∂ *QI’ve read in “Print Hints: Top 10 Printing Crimes” that a program shouldn’t call ° d ONLN d¬ø∂À˛ (Á‘
WaitNextEvent ° d ONLN d–À <◊ Ñ (Û Zwhile the Print ° d ONLN d‡À Ñ◊˛ )HKManager is open, but I call WaitNextEvent in my pIdleProc so my application ° d ONLN d,◊ <„O (ˇ Z;can detect a user cancellation. Could this cause a problem? ° d ONLN dh„ <Ô N * ___ ° d ONLN dl˚ < ’ * The reason you shouldn’t call ° d ONLN dä˚ ’˛ )ô8WaitNextEvent is to prevent the system from switching to ° d ONLN d√ < ’ (/ Z!another application. If you have ° d ONLN d‰ ’˛ )ô;a modal dialog-type window in front (the one with the modal ° d ONLN d < k (; Zwindow ° d ONLN d' k ˛ )/Iproc ID), the system will never switch applications and it’s safe to call ° d ONLN dq <+4 (G Z4WaitNextEvent. This is why all Apple’s drivers that ° d ONLN d• 4+˛ )¯(call WaitNextEvent put up a modal dialog ° d ONLN dŒ+ <7fl (S ZVbox. If you have a modal status window frontmost when your pIdle procedure is called, ° d ONLN d$+fl7˛ (S˝you’re ° d ONLN d+7 <C { (_ Z
in no danger.
° d ONLN d9[ <jM *'&Macintosh Printing Manager error -8132
° d ONLN d`j <v û * Date Written: 1/1/90 ° d ONLN dvv <Ç ´ * Last reviewed: 6/14/93 ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øÜ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) */What is Macintosh Printing Manager error -8132? ° d ONLN d 0 ) 5 * * ___ ° d ONLN d 4 A M+ *9Error -8132 is generated when the selected printer times ° d ONLN d m A+ M⁄ ( iI#out. AppleTalk printers monitor the ° d ONLN d ë M Y# ( u 67time between data packets that are sent to them. These ° d ONLN d » M# Y⁄ ( uA"devices will wait a maximum of two ° d ONLN d Î Y e i ( Å 6minutes without ° d ONLN d ˚ Y i e⁄ )QLdata until generating a time-out error. Applications such as database report ° d ONLN dH e q Á ( ç 6)generators sometimes require longer than ° d ONLN dq e Á q⁄ )œ/two minutes to sort or format their data. These ° d ONLN d° q } l ( ô 6applications may ° d ONLN d≤ q l }⁄ )THreceive the -8132 error. One workaround for this problem is to spool the ° d ONLN d˚ } âj ( • 6Jreport to a file that can be printed when sorting/formatting is completed. ° d ONLN dF ï °í *PAnother possible solution is to change the amount of time the LaserWriter waits ° d ONLN dñ ïí °⁄ ( Ω∞for data until it ° d ONLN d® ° ≠ ( … 61times out. Keep in mind that the time-out in the ° d ONLN dŸ ° ≠⁄ )Î+LaserWriter exists for a reason. Say a user ° d ONLN d ≠ π Ø ( ’ 6!starts printing a large document ° d ONLN d& ≠ Ø π⁄ )ó;and leaves for the day. About halfway through the document, ° d ONLN db π ≈ K ( · 6 the user’s ° d ONLN dm π K ≈⁄ )3PMacintosh crashes, leaving the printer waiting without data. In two minutes, the ° d ONLN dæ ≈ —¿ ( Ì 6WLaserWriter times out, and is once again available for other users on the net. However ° d ONLN d ≈¿ —⁄ ( Ìfiif the ° d ONLN d — ›7 ( ˘ 6=time-out is disabled by the first user’s job, the printer is ° d ONLN dY —7 ›⁄ ( ˘U useless until rebooted. To avoid ° d ONLN dz › È W ( 6disabling the ° d ONLN dà › W È⁄ )?Stime-out, increase the time-out value so that the device times-out if the job takes ° d ONLN d‹ È ı s ( 6too long to print, ° d ONLN dÔ È s ı⁄ )[Dbut does not time-out for normal delays. This is done by sending the ° d ONLN d4 ı Ñ ( 6Nfollowing Postscript to the LaserWriter with a Postscript downloading utility: ,
Courier
° d ONLN dÉ
Æ * serverdict begin 0 exitserver ° d ONLN d¢ " Í *
° d ONLN d ¿· ) *'&Macintosh Printing Manager error -8133
° d ONLN d Á ¸ z * Date Written: 1/1/90 ° d ONLN d ˝¸ Å * Last reviewed: 8/1/92 ° d ONLN d
*/What is Macintosh Printing Manager error -8133? ° d ONLN d
D , * * ___ ° d ONLN d
H8 D{ *KPrinting Manager error -8133 occurs when the PostScript interpreter of the ° d ONLN d
ì8{D⁄ (`ôLaserWriter (or any ° d ONLN d
ßD Pe (l 6Iother PostScript printer) generates a PostScript error. A description of ° d ONLN d
DeP⁄ (lÉthe PostScript command ° d ONLN d P \ ‚ (x 6*that caused the error is displayed in the ° d ONLN d 1P ‚\⁄ ) .status window. This error often occurs when an ° d ONLN d `\ h% (Ñ 6:application sends PostScript directly to the printer, and ° d ONLN d ö\%h⁄ (ÑC%that PostScript contains an error. To ° d ONLN d ¿h t (ê 65debug this problem, look at the PostScript generated ° d ONLN d ıht÷ )˙$by the driver. Hold down the Command ° d ONLN d h÷t⁄ )ƒ- ° d ONLN d t Ä g (ú 6F key right after ° d ONLN d ,t gÄ⁄ )ONclicking okay in the Print dialog. A file named PostScript0 will be created in ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ) s ( E Z the current ° d ONLN d s )˛ )7Rdirectory. With the 7.x LaserWriter drivers, just select the PostScript File radio ° d ONLN d _ ) < 5 µ ( Q Zbutton in the Print dialog.
° d ONLN d { M < \â *'2Identifying Macintosh’s currently selected printer
° d ONLN d Æ \ < h û * Date Written: 1/1/90 ° d ONLN d ƒ h < t • * Last reviewed: 8/1/92 ° d ONLN d € Ä < åÊ *WHow can I find out which printer the user has selected with the Macintosh Chooser? How ° d ONLN d2 ÄÊ å˛ ( ®can I ° d ONLN d8 å < ò ( ¥ Z,change it without going through the Chooser? ° d ONLN de ò < § N * ___ ° d ONLN di ∞ < º *.The type of the currently selected printer is ° d ONLN dó ∞ º˛ )‘/stored in the System file in 'STR ' resource ID ° d ONLN d« º < » å ( ‰ Z-8192. This will ° d ONLN dÿ º å »˛ )PKbe the name of the driver selected, such as LaserWriter or ImageWriter. The ° d ONLN d$ » < ‘ g ( Zname of ° d ONLN d, » g ‘˛ )+Uthe actual printer selected will be in the driver file (same name as the printer type ° d ONLN dÇ ‘ < ‡ı ( ¸ Z]chosen) in 'PAPA' resource ID -8192. Look at this resource with ResEdit to see what is in it. ° d ONLN d‡ Ï < ¯ ø *You can change the 'STR ' ° d ONLN d˙ Ï ø ¯˛ )É?and 'PAPA' resources, but it may not work now or in the future. ° d ONLN d: ¯ < ( Z$DTS does not recommend changing the ° d ONLN d^ ¯  )œ)system file or circumventing the Chooser! ° d ONLN dá ¯Â˛ )⁄ The ° d ONLN då <% (, Z1Chooser is a very complicated piece of software, ° d ONLN dΩ%˛ )È*and it has many dependencies. Implementing ° d ONLN dË < N (8 Zthe ° d ONLN dÏ N ˛ )Uchooser within your application would make your application dependent on a particular ° d ONLN dB <( c (D Zversion ° d ONLN dJ c(˛ )'Pof the system software. Like the Chooser, your application would then have to be ° d ONLN dõ( <4 (P Z+revised each time a new system is released.
° d ONLN d«L <[« *'9How to save Macintosh Page Setup and Print dialog options
° d ONLN d[ <g û * Date Written: 5/3/89 ° d ONLN dg <s ´ * Last reviewed: 6/14/93 ° d ONLN d/ <ãô *HHow do I save options set in the Macintosh Page Setup and Print dialogs? ° d ONLN dxã <ó N * ___ ° d ONLN d|£ <Ø ≈ *The only supported method ° d ONLN dñ£ ≈Ø˛ )â?to save the dialog options is to save the Print Record that was ° d ONLN d÷Ø <ªß (◊ ZLpassed to the PrStlDialog/PrJobDialog calls. This print record contains the ° d ONLN d"Øߪ˛ (◊≈options chosen in ° d ONLN d4ª <«g („ Z=the Page Setup and Print dialogs. Although these options are ° d ONLN dqªg«˛ („Ö saved in the print record, they ° d ONLN dë« <”• (Ô ZKcannot be used as defaults for the Print dialog. For example, say the user ° d ONLN d‹«•”˛ (Ô√chooses landscape ° d ONLN dÓ” <fl> (˚ Z7printing in the Page Setup dialog, and sets the number ° d ONLN d%”>fl˛ (˚\*of copies to 5 in the Print dialog. If the ° d ONLN dPfl <Î ∞ ( Zprint record is passed to ° d ONLN djfl ∞β )tEPrStlDialog, the dialog shows that landscape printing was selected in ° d ONLN d∞Î <˜ˆ ( Z[the print record. However, if that print record is passed to PrJobDialog, number of copies ° d ONLN d Έ˜˛ (is ° d ONLN d˜ <õ ( ZDshown as 1, because options in the PrJobDialog are considered to be ° d ONLN dR˜õ˛ ( π“job dependent,” as ° d ONLN df < ‚ (+ Z opposed to “document dependent.” ° d ONLN dá <' ê *The best method ° d ONLN dó ê'˛ )TJfor saving the print record is to save it as a resource in your document’s ° d ONLN d‚' <3} (O ZGresource fork. Since the print record is already pointed to by a valid ° d ONLN d )'}3˛ (Oõhandle, creating a resource ° d ONLN d E3 <? ‰ ([ Z%is easy. Here are the required steps: ° d ONLN d kK <W **1. Save the refNum returned by CurResFile; ° d ONLN d ñW <cÙ * [2. Make sure the resource fork of the document file is opened using OpenResFile (IM I:115). ° d ONLN d Úc <o¯ * ^3. Now that you have a place to put the resource, you must get the resource manager to create ° d ONLN d
Pc¯o˛ (ãit ° d ONLN d
So <{ ‹ (ó Z#for you. First, pick a type and ID ° d ONLN d
vo ‹{˛ )†9for your resource. You can use the Unique ID function (IM ° d ONLN d
∞{ <áD (£ Z6I:121) to generate the ID. Next, call the AddResource ° d ONLN d
Ê{DᲠ(£b$procedure (IM I:124). This procedure ° d ONLN d á <ì § (Ø Ztakes four parameters: ¡ X¡
± * S3. Be sure to pass the record that you get from your document to PrValidate before ° d ONLN df
±⁄ (5œ using it. ° d ONLN dp % ˘ (A 61This ensures that the record gets updated if any ° d ONLN d° ˘%⁄ )·-changes have been made to record structure or ° d ONLN dœ% 1 ƒ (M 6$contents since the record was saved.
° d ONLN dÙI X5 *')MacApp and SetRsl print driver resolution
° d ONLN d X d Ä * Date Written: 4/16/92 ° d ONLN d5d p á * Last reviewed: 6/14/93 ° d ONLN dM| à r *We’ve been trying ° d ONLN d_| rà⁄ )ZGto use the standardPrint handler from MacApp 2 to print some views. The ° d ONLN dßà î ì (∞ 6problem is that we would ° d ONLN d¿à ìî⁄ ){Dlike the printout to come out at 300 dpi on the LaserWriter, and the ° d ONLN dî †ô (º 6Uprint handler’s device resolution fields (which come from the device driver) tell it ° d ONLN dZîô†⁄ (º∑
to draw at 72 ° d ONLN dh† ¨† (» 6Ndpi. How, can I get a PenSize(1,1); MoveTo(100,100); LineTo(300,300); draw at ° d ONLN d∂††¨⁄ (»æ 300 dpi and ° d ONLN d¬¨ ∏U (‘ 6Cmake a nice fine line? Please refer me to the needed documentation. ° d ONLN d∏ ƒ * * ___ ° d ONLN d
– ‹í *OThe mechanism by which your application can find out the chosen printer’s real ° d ONLN dY–í‹⁄ (¯∞resolution, and ° d ONLN di‹ ËJ ( 6;then draw with it, is documented “Meet PrGeneral, the Trap ° d ONLN d§‹JË⁄ (hThat Makes the Most of the ° d ONLN døË Ù v ( 6Printing Manager,” ° d ONLN d“Ë vÙ Ω )^in issue #3 of ° d ONLN d·Ë ΩÙ ‚ )Gdevelop ° d ONLN dËË ‚Ù⁄ )%2 magazine (July 1990). You can find it, along with ° d ONLN dÙ ± ( 6Rits accompanying code and application, on the Developer CD, E.T.O., and AppleLink. ° d ONLN dn 0 *The ° d ONLN dr 0⁄ )FDTS Sample Code SC.009.FracApp300 on the Developer CD shows how to use ° d ONLN dπ $ (@ 60PrGeneral in an application built with MacApp 2.
° d ONLN dÍ? N» **@Printing patterns at higher resolutions with GetRslData & SetRsl
° d ONLN d +N Z Ä * Date Written: 11/7/90 ° d ONLN d BZ f á * Last reviewed: 6/14/93 ° d ONLN d Zr ~Q *EIs there a way that I can make my Macintosh fill patterns print at a ° d ONLN d ürQ~⁄ (öo higher resolution (more than ° d ONLN d º~ ä
(¶ 6672 dpi), but have my patterns still print as patterns? ° d ONLN d Ûä ñ * * ___ ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 5h ( Q Z=To make your patterns print at the printer’s resolution, you ° d ONLN d = )h 5˛ ( QÜ need to use Printing Manager ° d ONLN d Z 5 < A ≈ ( ] ZPrGeneral’s GetRslData and ° d ONLN d u 5 ≈ A˛ )â@SetRsl opcodes to get and set the resolution, and you must scale ° d ONLN d ∂ A < M Ë ( i Z%the pattern to match. Let me explain. ° d ONLN d ‹ Y < eÕ *UIf we do not scale our patterns up to the printer’s resolution before print time, we ° d ONLN d1 YÕ e˛ ( ÅÎ would get ° d ONLN d; e < q ( ç Z*“big chunky” patterns because the printer ° d ONLN de e q˛ )À2driver would need to scale the patterns on the fly ° d ONLN dò q < } ( ô Z*from 72 dpi to its resolution. Therefore, ° d ONLN d¬ q }˛ )«2we use the “cookie cutter” approach to “place” the ° d ONLN dı } < â § ( • Zpattern into the object ° d ONLN d
} § Ⲡ)hMthat is being filled. The size of the cookie cutter (that is, the destination ° d ONLN d[ â < ï∂ ( ± ZPRect) depends on the “scaleFactor”. For example, a scaleFactor of 2 will have a ° d ONLN d´ â∂ ï˛ ( ±‘destination rect ° d ONLN dº ï < °+ ( Ω Z2of 16 x 16. We will then CopyBits the pattern one ° d ONLN dÓ ï+ °˛ )Ô.square at a time into the object that is being ° d ONLN d ° < ≠ X ( … Zfilled. ° d ONLN d% π < ≈ ^ *XRefs: ° d ONLN d, ≈ < — ç * Inside Macintosh ° d ONLN d< ≈ ç —
)Q Volume V, pages 410-416 ° d ONLN dU — < › ó ( ˘ Z“Meet PrGeneral,” ° d ONLN dg — ó › ¿ )[develop, ° d ONLN do — ¿ › Ú ))
July 1990
° d ONLN dz ı <È ( Z@Call Printing Mgr’s bottleneck to send StdText to printer driver
° d ONLN dª < § * Date Written: 11/7/90 ° d ONLN d“ < ´ * Last reviewed: 6/14/93 ° d ONLN dÍ( <4 j *We need ° d ONLN dÚ( j4˛ ).Nto use the Macintosh toolbox call StdText instead of DrawChar, DrawString, and ° d ONLN dA4 <@Ô (\ ZWDrawText to accomplish horizontal scaling and fractional point sizes, but StdText does ° d ONLN dò4Ô@˛ (\
not ° d ONLN dú@ <LJ (h Z6work on the LaserWriter IISC. Is there any workaround? ° d ONLN d”L <X N * ___ ° d ONLN d◊d <p ¿ * The problem is that you are ° d ONLN dÛd ¿p˛ )ÑCcalling the low-level bottleneck directly, and the Printing Manager ° d ONLN d7p <| (ò Z0has replaced the bottleneck completely with its ° d ONLN dgp |˛ )‰+own. So when you are actually printing, the ° d ONLN dì| <à v (§ Z
print driver ° d ONLN d†| và˛ ):Pwill not see your call to StdText. The work-around for this is to call the Print ° d ONLN dÒà <îfl (∞ ZXManager’s bottleneck itself when you are printing. You can do this in the following way: ,
Courier
° d ONLN dJ† <´ æ */* typedef the function */ ° d ONLN de™ <µÜ *
Btypedef pascal void (*StdTextProcPtr)( short, Ptr, Point, Point ); ° d ONLN d®æ <… *,void tstDrawStuff( pInfo, thePort, pageNum ) ° d ONLN d’» <” } *
TPrint pInfo; ° d ONLN d„“ <› å *
GrafPtr thePort; ° d ONLN dÙ‹ <Á Ø *
unsigned short pageNum; ° d ONLN d Ê <Ò A *
{ ° d ONLN d <˚Y *
9 StdTextProcPtr Proc; /* declare a variable here */ ° d ONLN dH < √ */* do your clipping etc. */ ° d ONLN dd <# ‹ * /* TEST -- no good w/o PriMon */ ° d ONLN dÖ" <- π *
/* do your moveto etc. */ ° d ONLN dü6 <A *(/* Is there a replacement bottleneck ?*/ ° d ONLN d»@ <K » *
if ( thePort->grafProcs ) { ° d ONLN dÂJ <U¬ *
N Proc = (StdTextProcPtr)thePort->grafProcs->textProc; /* yes, so grab it */ ° d ONLN d4T <_m *
= (*Proc)( strlen("HELLO") , (Ptr) "HELLO", numer, denom ); ° d ONLN dr^ <i A *
} ° d ONLN dth <s Ê *
"/* else just call standard text */ ° d ONLN dór <} A *
° d ONLN d ) ô *This technique will work ° d ONLN d ô )⁄ )Å>in both background and foreground printing. I have tested this ° d ONLN d X ) 5≥ ( Q 6Vsolution on the Personal LaserWriter SC and the LaserWriter IINTX, and it prints fine.
° d ONLN d Ø M \Ω *'<Modifying PDEFs to have printer driver jump into dialog code
I JMP $0386 << At this point we jump into the printer ° d ONLN d
ÂZ eô *
M driver's original code for PrClosePage.
° d ONLN d 3p |U *?Note: The previous illustration is not to scale nor completely ° d ONLN d rpU|⁄ (òsaccurate in regards to the ° d ONLN d ç| à¿ (§ 6Yaddresses used. Please consult “Learning To drive” for the correct offsets for each PDEF. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < )À ( E ZRThen replace the original offset to PrClosePage with the offset to your new code. ° d ONLN d R À )˛ ( EÈRemember ° d ONLN d [ ) < 52 ( Q Z8that this is PC relative so you would calculate it like ° d ONLN d ì )2 5˛ )ˆ)this: If the original PrClosePage JMP was ° d ONLN d Ω 5 < Aä ( ] ZDJMP 10(SP) and the size of the original PDEF was 50 bytes, then you ° d ONLN d 5ä A˛ ( ]®need to replace the JMP ° d ONLN d A < M ( i Z+10(SP) with JMP 50-16(SP). In other words, ° d ONLN dD A M˛ )‹,you need to JMP to what was formerly the end ° d ONLN dq M < Y ( u Z)of the PDEF resource but what is now the ° d ONLN dö M Y˛ )“/beginning of your code (subtract 16 because the ° d ONLN d Y < eÕ ( Å ZWoffset table is 16 bytes long. Refer to “Learning to Drive” for more details). Then on ° d ONLN d! YÕ e˛ ( ÅÎ
the end of ° d ONLN d, e < q z ( ç Z your code, ° d ONLN d7 e z q˛ )>Eadd a JMP ((SizeOfJumpTable + originalOffset) – (sizeofOriginalPDEF + ° d ONLN d} q < }§ ( ô ZISizeOfYourCode))(SP). Your code will end with a JMP to a negative offset ° d ONLN dΔ q§ }˛ ( ô¬off the PC back to ° d ONLN dŸ } < â √ ( • Z the original PrCloseRoutine. ° d ONLN dˆ ï < ° ƒ * If you are willing to support ° d ONLN d ï ƒ °˛ )àAonly system software later than version 3.3 (basically that means ° d ONLN dV ° < ≠. ( … Z0that you won’t be supporting Macintosh 512K and ° d ONLN dÜ °. ≠˛ )Ú(512KE computers), you don’t have to deal ° d ONLN dØ ≠ < πñ ( ’ ZCwith all the PDEF changing, and you can simply patch out the $A8FD ° d ONLN dÚ ≠ñ π˛ ( ’¥trap and look for the ° d ONLN d π < ≈ Ö ( · Zproper selector ° d ONLN d π Ö ≈˛ )IMon the stack. (Use SysEnvirons to be sure that you are on a system later than ° d ONLN df ≈ < — Í ( Ì Z$version 3.3) This will work because ° d ONLN dä ≈ Í —˛ )Æ<the newer libraries (that is, any library that shipped since ° d ONLN d« — < › Ò ( ˘ Z'the Macintosh II shipped) first checks ° d ONLN dÓ — Ò ›˛ )µ:for the trap and jumps there if the trap exists so even if ° d ONLN d) › < ÈR ( Z>the application has linked in the printing library they still ° d ONLN dg ›R È˛ (p"end up calling the trap on systems ° d ONLN dä È < ı h ( Z
after 3.3.
° d ONLN dï
< Ê *'?Determining if printer supports color and/or grayscale printing
° d ONLN d’ <( § * Date Written: 3/14/91 ° d ONLN dÏ( <4 • * Last reviewed: 8/1/92 ° d ONLN d@ <L | *
Is there any ° d ONLN d@ |L˛ )@Lway to determine whether I’m printing to either a color printer or a printer ° d ONLN d]L <Xt (t ZBsimulating color, such as the LaserWriter set for Color/Grayscale? ° d ONLN d†X <d N * ___ ° d ONLN d§p <|c *>Check the grafPort returned by your call to PrOpenDoc. If the ° d ONLN d‚pc|˛ (òÅ rowBytes of the grafPort is less ° d ONLN d| <à Î (§ Z!than 0, the Printing Manager has ° d ONLN d$| Îà˛ )Ø2returned a color grafPort. You can then make Color ° d ONLN dWà <î è (∞ ZQuickDraw calls ° d ONLN dgà èî˛ )SLinto this grafPort. LaserWriter driver version 6.0 and later returns a color ° d ONLN d¥î <†´ (º ZMgrafPort from the PrOpenDoc call, if the Color/Grayscale button has been set. ° d ONLN d¨ <∏ *.The following code fragment demonstrates this: ,
Courier
° d ONLN d1ƒ <œÅ *A(* This function determines whether the port passed to it is a *) ° d ONLN dsŒ <ŸÅ *
A(* color port. If so, it returns TRUE. *) ° d ONLN dµÿ <„O *
7FUNCTION IsColorPort(portInQuestion: GrafPtr): BOOLEAN; ° d ONLN dÌ‚ <Ì U *
BEGIN ° d ONLN dÛÏ <˜' *
/ IF portInQuestion^.portBits.rowBytes < 0 THEN ° d ONLN d #ˆ < Ø *
IsColorPort := TRUE ° d ONLN d ; < Z *
ELSE ° d ONLN d B
< π *
IsColorPort := FALSE; ° d ONLN d \ < P *
END;
° d ONLN d a* <6 ˇ *+A third-party printer driver should return ° d ONLN d å* ˇ6˛ )√9the type of grafPort that represents the abilities of its ° d ONLN d Δ6 <BD (^ Z9printer. Therefore, if the printer supports color and/or ° d ONLN d ˇ6DB˛ (^b$grayscale, and if Color QuickDraw is ° d ONLN d
$B <N2 (j Z7present, the application will receive a color grafPort ° d ONLN d
[B2N˛ )ˆ*after calling PrOpenDoc. Otherwise, if the ° d ONLN d
ÜN <Z p (v Z
Macintosh ° d ONLN d
êN pZ˙ )4Myou’re running on does not support Color QuickDraw, you should return a black ° d ONLN d
° d ONLN d ,0 *(Using LaserWriter fonts with StyleWriter
° d ONLN d ) , 8 Ä * Date Written: 3/22/91 ° d ONLN d @ 8 D á * Last reviewed: 6/14/93 ° d ONLN d X P \ */Can StyleWriter use all the Adobe fonts for my ° d ONLN d á P \⁄ )¸&LaserWriter? Can StyleWriter print the ° d ONLN d Æ \ h/ ( Ñ 66encapsulated PostScript drawings I’ve developed? Does ° d ONLN d ‰ \/ h⁄ ( ÑM TrueType software come with the ° d ONLN d h t S ( ê 6 StyleWriter? ° d ONLN d t Ä * * ___ ° d ONLN d å ò ” *'The difference between the StyleWriter ° d ONLN d< å ” ò⁄ )ª7and a regular LaserWriter (other than one’s got a laser ° d ONLN dt ò § ° ( ¿ 6 and the other doesn’t) is that ° d ONLN dì ò ° §⁄ )âBthe LaserWriter has PostScript built-in; the StyleWriter does not. ° d ONLN d÷ § ∞ ¶ ( à 6 The StyleWriter, in fact, has ° d ONLN dÙ § ¶ ∞⁄ )é?nothing built-in, and only recognizes basic “put this dot here” ° d ONLN d4 ∞ ºk ( ÿ 6Ctypes of commands. Even sending it pure ASCII accomplishes nothing. ° d ONLN dx » ‘´ *UTrueType software is shipped with the StyleWriter, because it can image fonts at any ° d ONLN dÕ »´ ‘⁄ ( …
resolution ° d ONLN dÿ ‘ ‡ü ( ¸ 6Pwith excellent quality, much like PostScript. The TrueType software is intended ° d ONLN d( ‘ü ‡⁄ ( ¸Ω for users of ° d ONLN d5 ‡ Ï< ( 68system versions 6.0.7 and later, but prior to System 7. ° d ONLN dm ‡< Ïs (Z System 7 ° d ONLN dv ‡s Ïö )7includes ° d ONLN d~ ‡ö Ï⁄ )' support for ° d ONLN dã Ï ¯ J ( 6 TrueType. ° d ONLN dï ¯ *(You can use PostScript images and fonts ° d ONLN dΩ ¯⁄ )‡*with the StyleWriter, but just as with the ° d ONLN dË Î (8 6+ImageWriter, you’ll have to have something ° d ONLN d Î ⁄ )”.that images them in memory before sending them ° d ONLN dB (x (D 6Mto the printer (in other words, a Macintosh-resident PostScript interpreter).
° d ONLN dê@ OC *',Personal LaserWriter LS 1.1 driver is faster
° d ONLN dΩO [ z * Date Written: 8/9/91 ° d ONLN d”[ g á * Last reviewed: 6/14/93 ° d ONLN dÎs ¬ *SMy LaserWriter LS is very slow when printing from my Macintosh SE. Any suggestions? ° d ONLN d? ã * * ___ ° d ONLN dCó £ Á **Use the new LaserWriter LS driver version ° d ONLN dmó Á£⁄ )œ31.1 or later. It was released after System 7.0, and ° d ONLN d°£ Ø Û (À 6.is available on AppleLink or from your dealer. ° d ONLN d–ª «D *9If you’re printing Word files, Microsoft’s TrueType INIT ° d ONLN d ªD«⁄ („b will help. It’s available from ° d ONLN d(« ”r (Ô 6GMicroSoft Technical Support or from commercial bulletin board services.
° d ONLN dpÎ ˙´ *'9ImageWriter II 6.1 & 7.0 driver PrGeneral/PrStlDialog bug
° d ONLN d™˙ Ä * Date Written: 9/11/91 ° d ONLN d¡ á * Last reviewed: 6/14/93 ° d ONLN dŸ * 1 *If an ° d ONLN dfl 1*⁄ )Wapplication uses PrGeneral to set draftBits mode on an ImageWriter II (using the 6.1 or ° d ONLN d7* 6 U (R 6
7.0 drivers) ° d ONLN dD* U6⁄ )=Mand then does a PrStlDialog, a fatal crash occurs. This happens with both the ° d ONLN dí6 B3 (^ 67AppleTalk and non-AppleTalk drivers. This only happens ° d ONLN d…63B⁄ (^Q on Macintosh systems with Color ° d ONLN dÈB N R (j 6
<^ *:(* Sample snippet that demonstrates how to work-around the ° d ONLN dÕ <"T *
8 'dctb' bug in the ImageWriter II 6.1 and 7.0 drivers. ° d ONLN d! <,' *
/ Bug causes a crash when doing a style dialog ° d ONLN d6+ <6 *
* after setting draftbits with PrGeneral. ° d ONLN da5 <@ K *
*) ° d ONLN deI <T A *{ ° d ONLN dgS <^' *
/ What's what in the code snippet that follows. ° d ONLN dög <r ◊ * thePrRecHdl : THPrint; ° d ONLN d∫q <| Ê *
" rslData : TSetRslBlk; ° d ONLN d›{ <Ü Î *
# draftData : TDftBitsBlk; ° d ONLN dÖ <ê Î *
# rotnData : TGetRotnBlk; ° d ONLN d%è <ö ◊ *
isBadImageWriter : Boolean; ° d ONLN dEô <§ ◊ *
isLandscape : Boolean; ° d ONLN de£ <Æ ◊ *
isReduced : Boolean; ° d ONLN dÖ≠ <∏ A *
} ° d ONLN dá¡ <Ã } *
PrOpen; ° d ONLN dï’ <‡ Õ * IF (PrError = noErr) THEN ° d ONLN d≥fl <Í i *
BEGIN ° d ONLN dΩÛ <˛ ‹ * PrintDefault(thePrRecHdl); ° d ONLN dfi < ◊ * IF (PrError = noErr) THEN ° d ONLN d˛ < s *
BEGIN ° d ONLN d
% <0m *={See if we're using a version 6.1 or 7.0 ImageWriter driver.} ° d ONLN dH9 <DJ *6 IF (thePrRecHdl^^.prStl.wDev DIV 256) = 1 THEN ° d ONLN dC <Nê *
D isBadImageWriter := (PrDrvrVers = 61) OR (PrDrvrVers = 70) ° d ONLN dƒM <X x *
ELSE ° d ONLN d—W <b *
$ isBadImageWriter := FALSE; ° d ONLN d k <v ˙ *& IF NOT (isBadImageWriter) THEN ° d ONLN d (u <Ä } *
BEGIN ° d ONLN d 6â <î6 *2{Set draftBits mode now, if not our special case.} ¡ X¡
° d ONLN d ' 2 Ô *!+ draftData.iOpCode := draftBitsOp; ° d ONLN d , 1 < Í *
* draftData.hPrint := thePrRecHdl; ° d ONLN d W ; F ∏ *
PrGeneral(@draftData); ° d ONLN d x O Z T * END; ° d ONLN d Ö c n Ü *{Do the style dialog.} ° d ONLN d ú w Ç Í ** IF (PrStlDialog(thePrRecHdl)) THEN ° d ONLN d « Å å Ã *
$ IF (isBadImageWriter) THEN ° d ONLN d Ï ã ñ c *
BEGIN ° d ONLN d ¸ ü ™0 *8{If so, see if they selected rotation or 50% reduction.} ° d ONLN d@ ≥ æ Í ** rotnData.iOpCode := getRotnOp; ° d ONLN dk Ω » Ô *
+ rotnData.hPrint := thePrRecHdl; ° d ONLN dó « “ Ω *
! PrGeneral(@rotnData); ° d ONLN dπ € Ê */ isLandscape := rotnData.fLandscape; ° d ONLN dÈ Ô ˙? *; isReduced := BTst(thePrRecHdl^^.prStl.wDev, 3); ° d ONLN d% *4{If so, warn them that those things will be ignored. ° d ONLN dZ
! *
5 Preferably use something other than DebugStr… } ° d ONLN dõ! , *0 IF (isLandscape) OR (isReduced) THEN ° d ONLN dÃ+ 6q *
E DebugStr('Bad ImageWriter; landscape and/or reduced.'); ° d ONLN d? J *2{Now, set draftBits mode, since we didn't before.} ° d ONLN dES ^ ˘ *- draftData.iOpCode := draftBitsOp; ° d ONLN ds] h Ù *
, draftData.hPrint := thePrRecHdl; ° d ONLN d†g r ¬ *
" PrGeneral(@draftData); ° d ONLN d√{ Ü ^ * END; ° d ONLN d“è ö Ù *, IF (PrJobDialog(thePrRecHdl)) THEN ° d ONLN d ô § c *
BEGIN ° d ONLN d≠ ∏ w * {Print} ° d ONLN d$¡ Ã ^ * END; ° d ONLN d3À ÷ J *
END; ° d ONLN d>’ ‡ @ *
END; ° d ONLN dGÈ Ù T * PrClose;
° d ONLN dT k *&2How to abort printing while PrPicFile is executing
° d ONLN dá & Ä * Date Written: 9/27/91 ° d ONLN dû& 2 á * Last reviewed: 6/14/93 ° d ONLN d∂> Jì *OCan I abort printing from within PrPicFile? My attempts haven’t been succesful. ° d ONLN dJ V * * ___ ° d ONLN d
b n º *"The following Pascal procedure is ° d ONLN d,b ºn · )§roughly ° d ONLN d3b ·n ı )% the ° d ONLN d8b ın⁄ ).same as the default idle procedure—the one the ° d ONLN dgn zO (ñ 6>system supplies for you when you don’t supply one of your own: ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X / ,
Courier
° d ONLN d < ( √ ( D Zprocedure MyPIdleProcedure; ° d ONLN d ' < 2 U *
var ° d ONLN d " 1 < < Ê *
" pIdleEventRecord: EventRecord; ° d ONLN d E ; < F _ *
begin ° d ONLN d M E < PO *
7 if GetNextEvent(keyDownMask, pIdleEventRecord) then ° d ONLN d Ö O < Z s *
begin ° d ONLN d ë Y < dm *
= if ((BitAnd(pIdleEventRecord.message, charCodeMask) = ° d ONLN d – c < n √ *
longint('.')) and ° d ONLN d Ï m < xr *
> (BitAnd(longint(pIdleEventRecord.modifiers), cmdKey) = ° d ONLN d, w < Ç Ø *
cmdKey)) then ° d ONLN dD Å < å · *
! PrSetError(iPrAbort); ° d ONLN df ã < ñ n *
end; ° d ONLN dq ï < † Z *
end;
° d ONLN dx ´ < ∑ Ú *)(This is written in Think Pascal, but it ° d ONLN d° ´ Ú ∑˛ )∂3should work fine under MPW Pascal if you change the ° d ONLN d’ ∑ < √ Ÿ ( fl Z “BitAnd” functions to “BAND”.) ° d ONLN dÙ œ < €û *CAs you can see, the system aborts when you press Command-period by ° d ONLN d7 œû €˛ ( ˜ºusing PrSetError to ° d ONLN dK € < Áì ( ZFthe constant iPrAbort, which is the same error returned when the user ° d ONLN dë €ì Á˛ (±clicks “Cancel” in the ° d ONLN d® Á < Ûi ( ZCstyle or job dialogs. If you set the error to iPrAbort, the system ° d ONLN dÎ Ái Û˛ (á will take care of the rest. Your ° d ONLN d Û < ˇÕ ( ZRprint loop will also gracefully cancel, provided you follow the guidelines in the ° d ONLN d^ ÛÕ ˇ˛ (Î Macintosh ° d ONLN dh ˇ < (' Z,Technical Note “A Printing Loop That Cares.”
° d ONLN dï# <2O *'(Disabling ImageWriter’s initial formfeed
NoGaps: BOOLEAN; ° d ONLN d∑ ˘ 1 *BEGIN ° d ONLN dΩ w *
GetPort(oldPort); ° d ONLN d—
*
1 thePrRec := THPrint(NewHandle(SIZEOF(TPrint))); ° d ONLN d " E *
PrOpen; ° d ONLN d
! , ≥ *
IF PrError = noErr THEN BEGIN ° d ONLN d-+ 6 ü *
PrintDefault(thePrRec); ° d ONLN dI? J — *% IF NOT PrStlDialog(thePrRec) THEN ° d ONLN doI T ü *
PrSetError(iPrAbort); ° d ONLN dãS ^ — *
% IF NOT PrJobDialog(thePrRec) THEN ° d ONLN d±] h ü *
PrSetError(iPrAbort); ° d ONLN dÕq |Ö *I (* First, lock the handle down so we can do a cool with statement. *) ° d ONLN d{ Ü § *
HLock(Handle(thePrRec)); ° d ONLN d4Ö ê ü *
IF PrError = noErr THEN ° d ONLN dPè ö § *
WITH thePrRec^^ DO BEGIN ° d ONLN dmô §ä *
J (* Okay, now get device dependent. We only want to do this if we *) ° d ONLN d∏£ Æä *
J (* know the selected printer driver supports it. *) ° d ONLN d≠ ∏ *
2 IF (HiByte(prStl.wDev) = bDevImageWriter) OR ° d ONLN d6∑ ¬5 *
9 (HiByte(prStl.wDev) = bDevImageWriterLQ) THEN BEGIN ° d ONLN dpÀ ÷g *C (* Now remember the state of the nogaps option. *) ° d ONLN d¥’ ‡ Í *
* NoGaps := BitTst(@prStl.wDev, 11); ° d ONLN dflÈ ÙÖ *I (* If NoGaps was selected, then turn it off until we PrOpenDoc.*) ° d ONLN d)Û ˛
*
1 IF (NoGaps) THEN BitClr(@prStl.wDev, 11); ° d ONLN d[ Ö *I (* If we're on the LQ driver, we need to copy the wDev into the*) ° d ONLN d• Ö *
I (* PrintX array, or the LQ driver won't notice that it changed.*) ° d ONLN dÔ &0 *
8 IF (HiByte(prStl.wDev) = bDevImageWriterLQ) THEN ° d ONLN d(% 0 ¬ *
" PrintX[2] := prStl.wDev; ° d ONLN dK/ : J *
END; ° d ONLN dV9 D @ *
END; ° d ONLN d_C N Æ *
HUnlock(Handle(thePrRec)); ° d ONLN d~W b ∏ * (* Now open the document. *) ° d ONLN düa l *
/ thePrPort := PrOpenDoc(thePrRec, NIL, NIL); ° d ONLN dœu ÄÖ *I (* Now we need to see if the NoGaps option was selected. If it was *) ° d ONLN d äÖ *
I (* then we turned it off before calling PrOpenDoc, so we need to *) ° d ONLN dcâ îÖ *
I (* turn it back on. If wasn't selected, we won't do anything. *) ¡ 4¡˘
H InitMenus; {initialize Menu Manager} ° d ONLN dô <§ê *
D TEInit; {initialize TextEdit} ° d ONLN d\£ <Æï *
E InitDialogs(NIL); {initialize Dialog Manager} ° d ONLN d¢≠ <∏≥ *
K InitCursor; {call QuickDraw to make cursor (pointer) an arrow} ° d ONLN dÓ¡ <Ã } *
PrintStuff; ° d ONLN d¸À <÷ P *
END.
° d ONLN dÌ <¸Ñ *&1Update Macintosh color table if printing in color
° d ONLN d3¸ < û * Date Written: 5/3/89 ° d ONLN dI < ´ * Last reviewed: 6/14/93 ° d ONLN da <,ú *GI’m having trouble printing in color. When I copy a color image from a ° d ONLN d® ú,˛ (H∫Macintosh offscreen ° d ONLN dº, <8π (T ZUpixmap to the printer, I get a black piece of paper. If I draw directly it comes out ° d ONLN d,π8˛ (T◊
fine. What am ° d ONLN d 8 <D Ö (` ZI doing wrong? ° d ONLN d.D <P N * ___ ° d ONLN d2\ <hÉ *EWhen you built your offscreen port and copied the color table from a ° d ONLN dw\Éh˛ (Ñ°GDevice, did you change ° d ONLN dèh <tõ (ê ZLthe color table to reflect that the color table is now part of a pixmap? In ° d ONLN d€hõt˛ (êπa GDevice the color ° d ONLN dÔt <ÄQ (ú Z=table’s value field is zero for all entries, but in a pixmap ° d ONLN d,tQIJ (úo$the value field represents the index ¡ X¡
(÷ Z PR 515 - Printing Manager Q&As (÷˙13 )
of 14 (Ï ZM.PR.PrtMgr.Q&As ˇ™ ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) π *%value of each color in the table. If ° d ONLN d % π )⁄ )°;the color table has not been converted, printing won’t work ° d ONLN d a ) 5 D ( Q 6 properly. ¡ 4¡˘
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Å. ( õ ZPR 520 - PrintMonitor Q&As
° d ONLN d Ä < è s *Printing
° d ONLN d % õ < ß t * Revised by: ° d ONLN d 1 õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d J õ± ߲ ( √œSeptember 1993 ° d ONLN d Y ß < ≥ q ( œ Z Written by: ° d ONLN d e ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d ~ ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d ã ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ™ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d ‰ À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d+ À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN d> ◊ < „ u ( ˇ Z
While DSC ° d ONLN dH ◊ u „˛ )9Lengineers have checked the Q&A content for accuracy, the Q&A Technical Notes ° d ONLN dï „ < Ô q ( Z don’t have ° d ONLN d† „ q Ô˛ )5Qthe editing and organization of other Technical Notes. The Q&A function is to get ° d ONLN dÚ Ô < ˚ Ÿ ( Z new technical information and ° d ONLN d Ô Ÿ ˚˛ )ù6updates to you quickly, saving the polish for when the ° d ONLN dG ˚ < (# Z,information migrates into reference manuals. ° d ONLN dt < k *:Q&As are now included with Technical Notes to make access ° d ONLN dÆk ˛ (;â to technical updates easier for ° d ONLN dŒ <+. (G Z/you. If you have comments or suggestions about ° d ONLN d˝ .+˛ )Ú*Q&A content or distribution, please let us ° d ONLN d(+ <7 \ (S Zknow ° d ONLN d-+ \7˛ ) Iby sending an AppleLink to DEVFEEDBACK. Apple Partners may send technical ° d ONLN dw7 <Ci (_ Z9questions about Q&A content to DEVSUPPORT for resolution. ° d ONLN d±O <[ · * New Q&As in this Technical Note: ° d ONLN d“[ <g4 * 2Determining whether background printing is enabled í Xí
° d ONLN då <õù *42Determining whether background printing is enabled
° d ONLN d8õ <ß ô * 62755 MD JM dy 1 ° d ONLN dIß <≥ § * Date Written: 1/20/93 ° d ONLN d`≥ <ø ´ * Last reviewed: 4/26/93 ° d ONLN dxÀ <◊Æ *OHow can I tell whether background printing is enabled for the selected printer? ° d ONLN d»◊ <„ N * ___ ° d ONLN dÃÔ <˚N *7There’s no procedure to determine whether the user has ° d ONLN dÔN˚˛ (l"picked background printing because ° d ONLN d&˚ <" (# Z0that’s not a standard Macintosh system software ° d ONLN dV˚"˛ )Ê-feature. Where it’s done, it’s implemented on ° d ONLN dÑ <¨ (/ ZSa driver-by-driver basis, and each printer driver keeps track of it in a different ° d ONLN d◊¨˛ (/ way. Apple does ° d ONLN dÁ < « (; ZPit one way, Hewlett-Packard might do it another way, GCC a third way, and so on. ° d ONLN d8+ <7á *DSince we don’t actually know how it’s done, and since Apple doesn’t ° d ONLN d|+á7˛ (S•guarantee its drivers will ° d ONLN dó7 <C‹ (_ ZWdo it the same way in the future as they do now, we have no information to give you on ° d ONLN dÓ7‹C˛ (_˙how to ° d ONLN dıC <O, (k Z3determine this. Sorry to be the bearer of bad news.
° d ONLN d)g <vR *')Location for spool files under System 7.0
° d ONLN dSv <Ç ™ * Date Written: 12/18/90 ° d ONLN dkÇ <é • * Last reviewed: 8/1/92 ¡ X¡
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† øö ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d ) 5≠ *$XIs there a recommended location for printer driver writers to put their own spool files? ° d ONLN d Y 5 A * * ___ ° d ONLN d ] M Y *7Place it in the “PrintMonitor Documents” folder within ° d ONLN d î M Y⁄ ( u:'a “personal spool” folder. PrintMonitor ° d ONLN d º Y eí ( Å 6Uwill ignore other folders and it will delete its spool file when it was done with it. ° d ONLN d q }9 *?The biggest advantage with this approach is that all the spool ° d ONLN dQ q9 }⁄ ( ôW"files end up in the same location, ° d ONLN dt } â ( • 68which is probably the best solution for the native user. ° d ONLN d≠ ï °Ã *_There are a few cases when the folder might not be present (such as if the user has deleted it ° d ONLN d ïà °⁄ ( ΩÍfor ° d ONLN d ° ≠ú ( … 6Rsome reason). Therefore, you should check to make sure that the folder is present ° d ONLN db °ú ≠⁄ ( …∫
before trying ° d ONLN dp ≠ π® ( ’ 6Uto add a file to it. If it is not present, be sure to create it with the exact name; ° d ONLN d≈ ≠® π⁄ ( ’Δ
otherwise, ° d ONLN d– π ≈ê ( · 6PPrintMonitor will not be able to find it and will create a second folder with a ° d ONLN d πê ≈⁄ ( ·Ædifferent name, ° d ONLN d0 ≈ —' ( Ì 66possibly confusing the native user. Folder management ° d ONLN df ≈' —⁄ ( ÌE&is relatively straightforward with the ° d ONLN dç — › œ ( ˘ 6$addition of the “Folder Manager” to ° d ONLN d± — œ ›Ü )∑"System 7.0. The Finder chapter in ° d ONLN d” —Ü ›⁄ )∑Inside Macintosh ° d ONLN d‰ › È Ô ( 6.Volume VI contains the details about using it.
° d ONLN d á *'4Determining whether background printing is turned on
° d ONLN dH z * Date Written: 2/5/92 ° d ONLN d^ ( Å * Last reviewed: 8/1/92 ° d ONLN du4 @Ω *SI need to know whether the currently chosen printer driver—that I’m about to print ° d ONLN d»4Ω@⁄ (\€to—is ° d ONLN dŒ@ L Û (h 6)going to be doing background printing or ° d ONLN d˜@ ÛL⁄ )€-not. The user interface of our application is ° d ONLN d%L X. (t 6:somewhat different, depending on this. Currently, I check ° d ONLN d_L.X⁄ (tL%the driver’s file type to see whether ° d ONLN dÖX d h (Ä 6it’s network- or ° d ONLN dñX hd⁄ )PIlocal-attached, generalizing “network = LaserWriter = background capable” ° d ONLN d‡d p (å 64and “direct = ImageWriter = foreground only,” but I ° d ONLN ddp⁄ )˙)know this isn’t always correct, because a ° d ONLN d>p |“ (ò 6^variety of direct-connect printer drivers now support background printing. What I really need ° d ONLN dúp“|⁄ (òis ° d ONLN dü| àj (§ 6Ha way to check specifically for background printing being turned on. Is ° d ONLN dÁ|jà÷ (§àthere a safe and driver ° d ONLN d˛|÷à⁄ )l- ° d ONLN dˇà î ´ (∞ 6 independent way to check this? ° d ONLN d î † * * ___ ° d ONLN d"¨ ∏ √ *#No, there’s absolutely no safe and ° d ONLN dE¨ √∏⁄ )´6driver-independent way to do this. Although Apple uses ° d ONLN d|∏ ƒ» (‡ 6]PrintMonitor for all background printing, it’s not designed for third-party products to hook ° d ONLN dŸ∏»ƒ⁄ (‡Êinto ° d ONLN dfiƒ – < (Ï 6it. The ° d ONLN dʃ <–⁄ )$R“background printing” internals aren’t documented because changing that outside an ° d ONLN d9– ‹T (¯ 6Findividual printer driver may not give the driver all the information ° d ONLN d–T‹⁄ (¯r it needs to correctly print in ° d ONLN dû‹ Ë1 ( 6<the background. Also, third parties have to implement their ° d ONLN d⁄‹1ËF (Oown ° d ONLN d›‹FËI ) ° d ONLN dfi‹IË⁄ ) background printing schemes, ° d ONLN d˚Ë Ù< ( 6:and there’s absolutely no way to know how they’re storing ° d ONLN d 5Ë<Ù⁄ (Z the choice on whether or not to ° d ONLN d UÙ ä ( 6print in the background. ° d ONLN d n Æ *VIf your user interface is substantially different, you may need to require your users ° d ONLN d ƒ Æ⁄ (4à to enable ° d ONLN d Œ $ † (@ 6 background printing in your ° d ONLN d Í †$⁄ )àCapplication as well as in the Chooser. This isn’t exactly friendly, ° d ONLN d
.$ 0Ç (L 6Lbut since there’s no mechanism for applications to communicate with printer ° d ONLN d
z$Ç0⁄ (L†drivers to find out ° d ONLN d
é0 << (X 6=about background printing, it’s pretty much your only choice. ° d ONLN d
ÃH T∂ *[You’re right, checking a driver’s file type to see whether it’s network- or local-attached ° d ONLN d 'H∂T⁄ (p‘is not a ° d ONLN d 0T `% (| 68good solution. StyleWriters and LaserWriter LS printers ° d ONLN d hT%`⁄ (|C%print in the background but don’t use ° d ONLN d é` lƒ (à 6Ya network. Some third-party laser printers support AppleTalk but not background printing. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d < ,ë ( H Z0Turning Macintosh background printing on and off
° d ONLN d 1 , < 8 § * Date Written: 3/25/92 ° d ONLN d H 8 < D ´ * Last reviewed: 6/14/93 ° d ONLN d ` P < \Ü *ESomeone has requested that we do an extension for our application to ° d ONLN d • PÜ \˛ ( x§turn background printing ° d ONLN d æ \ < h
° d ONLN d ) n *which defines the ° d ONLN d n )⁄ )VLclipping region for the port. All subsequent PostScript code will be clipped ° d ONLN d _ ) 5 ( Q 68correctly. Since PrOpenPage resets the clipping region, ° d ONLN d ó ) 5⁄ ( Q>#the MoveTo/Line combination must be ° d ONLN d ª 5 A ¿ ( ] 6#done after each call to PrOpenPage.
° d ONLN d fl Y h *'!SetOrigin and background printing
° d ONLN d h t z * Date Written: 1/1/90 ° d ONLN d t Ä á * Last reviewed: 6/14/93 ° d ONLN d/ å ò ] *I have noticed ° d ONLN d> å ] ò⁄ )EOPostScript graphics printing in different locations depending on whether or not ° d ONLN dé ò §[ ( ¿ 6BBackground printing is enabled on the Macintosh. What causes this? ° d ONLN d— § ∞ * * ___ ° d ONLN d’ º » */In LaserWriter 4.0 - 5.2, SetOrigin is handled ° d ONLN d º »⁄ )Ù'differently when Background printing is ° d ONLN d, » ‘@ ( 6=enabled. The method used by these drivers is described below: ° d ONLN dj ‡ Ïh *CBackground Printing DISABLED: The application calls SetOrigin, and ° d ONLN d≠ ‡h Ï⁄ (ÜQuickDraw responds to ° d ONLN d√ Ï ¯, ( 6:the call by adjusting the portRect of the Print Manager’s ° d ONLN d˝ Ï, ¯⁄ (J"GrafPort. Since SetOrigin does not ° d ONLN d ¯ Δ ( 6Scause any grafProcs to run, the Printing Manager doesn’t see this change until the ° d ONLN ds ¯Δ⁄ ( ‰next ° d ONLN dx Ä (, 6BQuickDraw drawing operation such as DrawString or LineTo. At that ° d ONLN d∫Ä⁄ (,ûtime, the Printing ° d ONLN dÕ j (8 6Manager notices ° d ONLN d› j ⁄ )RJthe change in the portRect, and updates its internal origin. All QuickDraw ° d ONLN d( ( · (D 6&graphics are now localized to the new ° d ONLN dN ·(⁄ )…1origin. All PostScript graphics will also get the ° d ONLN dÄ( 4 § (P 6 localization to the new origin. ° d ONLN d†@ L« *NBackground Printing ENABLED: Because QuickDraw is playing back a picture that ° d ONLN dÓ@«L⁄ (hÂwas ° d ONLN dÚL XS (t 6Espooled earlier, it handles calls to SetOrigin a little differently. ° d ONLN d7LSX⁄ (tqWhen the SetOrigin call is ° d ONLN dRX d) (Ä 67encountered in a DrawPicture call, the portRect of the ° d ONLN dâX)d⁄ (ÄG!GrafPort is NOT updated. Instead, ° d ONLN d´d pà (å 6VQuickDraw keeps the current origin cached, and offsets each graphic on the fly. Since ° d ONLN ddÃp⁄ (åÍthe ° d ONLN dp | ≠ (ò 6 portRect was not modified, the ° d ONLN d$p ≠|⁄ )ï>Printing Manager does not see the SetOrigin call. Although all ° d ONLN dc| àπ (§ 6TQuickDraw objects are still localized correctly (by QuickDraw), PostScript graphics ° d ONLN d∑|πà⁄ (§◊do not ° d ONLN dæà îL (∞ 6?move to the new origin. Instead, the application localizes the ° d ONLN d˝àLî⁄ (∞j coordinates of its PostScript ° d ONLN dî † b (º 6graphics. You ° d ONLN d)î b†÷ )JGcould also use the technique documented in the Technical Note “Position ° d ONLN dpî÷†⁄ (ºÙ- ° d ONLN dq† ¨ è (» 6Independent PostScript.” ° d ONLN dä∏ ƒP *@The implementation of the SetOrigin (IM I:166) and ClipRect (IM ° d ONLN d ∏Pƒ⁄ (‡n I:167) calls has been revised ° d ONLN d˃ –O (Ï 6Cin LaserWriter 6.0. This is a general description of those changes: ° d ONLN d,‹ Ëà *VLaserWriter 6.0: Both QuickDraw and PostScript coordinates are offset with respect to ° d ONLN dÇ‹ÃË⁄ (Íthe ° d ONLN dÜË Ùw ( 6Korigin set by SetOrigin. The driver now inserts a picture comment into the ° d ONLN d—ËwÙ⁄ (ïspool file so that the ° d ONLN dËÙ Q ( 6@Print Monitor knows that the origin was changed during spooling. ° d ONLN d ) ˙ *0Since applications must support versions of the ° d ONLN d Y ˙⁄ )‚.LaserWriter driver other than 6.0, they should ° d ONLN d à $k (@ 6Dstill use the method described in this Tech Note to make sure their ° d ONLN d Ãk$÷ (@âPostScript is position ° d ONLN d ‚÷$⁄ )k- ° d ONLN d „$ 0 U (L 6 independent. ° d ONLN d < H 9 *X-Ref: ° d ONLN d ˜H TR * >DTS Macintosh Technical Note “Position-Independent PostScript”
° d ONLN d
6l {C *'-Macintosh spool file formats aren’t available
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 5Ø ( Q ZMWhat is file format of Macintosh Printing Manager and LaserShare spool files? ° d ONLN d N 5 < A N * ___ ° d ONLN d R M < Yù *OUnfortunately, the formats for these files are not currently available, and it ° d ONLN d ° Mù Y˛ ( uªis doubtful that they ° d ONLN d ∑ Y < eÄ ( Å Z@will be made available in the future. Whenever new features are ° d ONLN d ˜ YÄ e˛ ( Åûadded to LaserShare, the ° d ONLN d e < q ‰ ( ç Z$Printing Manager, or other parts of ° d ONLN d4 e ‰ q˛ )®8the Macintosh toolbox, it’s not uncommon for these spool ° d ONLN dm q < }« ( ô ZXfile formats to be affected. If the file format were published, and essentially frozen, ° d ONLN d≈ q« }˛ ( ôÂ it would be ° d ONLN d— } < â ( • Z,much harder for engineering to add features. ¡ X¡
ONLN f ˛ † å ° d 1drw2 … -·_ Ä ˇˇˇˇˇˇ è ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˙ ó@ † ò , Times
. R… R… +]BNew Technical Notes † ô ° d drw2 : °„ † ó ° d 1drw2 eÙ Ä ˇˇˇˇˇˇ P ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä E¿ † ò
( {ïDeveloper Support † ô ° d drw2 : °„ † ó ° d `drw2 - Ô ˇˇˇˇˇˇ K Ô - Z f f Z ° d 1drw2 ¿˙È ˇˇˇˇˇˇ K ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : 0 ° ö ˇÙ Ä † ò
0 ( UÔ † ô ° d drw2 : °„ † ó ° d 1drw2 ÔÊ˙ ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˝Ä † ò
+& ® † ô ° d drw2 : °„ † ó ° d 1drw2  -¯ y ˇˇˇˇˇˇ ° ñ x ° d drw2 : ° d drw2 : $ ° d 4drw2 : ° ö ˇ˚Ä % † ò
( Z \ Macintosh † ô ° d drw2 : °„ † ó † ç ° d drw2 D † É
IR . ° d ONLN d n < Åã ( õ Z#PR 525 - QuickDraw GX Printing Q&As
° d ONLN d $ Ä < è s *Printing
° d ONLN d . õ < ß t * Revised by: ° d ONLN d : õ Ñ ß ˇ )HDeveloper Support Center ° d ONLN d S õ± ߲ ( √œSeptember 1993 ° d ONLN d b ß < ≥ q ( œ Z Written by: ° d ONLN d n ß Ñ ≥ ˇ )HDeveloper Support Center ° d ONLN d á ßæ ≥˛ ( œ‹ October 1990 ° d ONLN d î ø < À ⁄ ( Á Z This Technical Note contains a ° d ONLN d ≥ ø ⁄ À˛ )û9collection of Q&As relating to a specific topic—questions ° d ONLN d Ì À < ◊† ( Û ZGyou’ve sent the Developer Support Center (DSC) along with answers from ° d ONLN d4 À† ◊˛ ( Ûæthe DSC engineers. ° d ONLN dG ◊ < „ u ( ˇ Z
userdict /_cv known not{userdict /_cv 30 dict put}if
_cv begin
/bdf{bind def}bind def
currentscreen/cs exch def/ca exch def/cf exch def
/setcmykcolor where{/setcmykcolor get /cvcmyk exch def}{/cvcmyk{1 sub 4 1 roll 3{3 index add neg dup 0 lt{pop 0}if 3 1 roll}repeat setrgbcolor pop}bdf }ifelse
/ss{//cf //ca //cs setscreen}bdf
/stg{ss setgray}bdf
/strgb{ss setrgbcolor}bdf
/stcmyk{ss cvcmyk}bdf
/min1{dup 0 eq{pop 1}if}bdf
end
currentdict /bn known {bn}if
† ø
å ◊# ˇ ˇˇˇˇ # ◊
IR , Times
. +6-Macintosh Technical Notes / 4 /˘
° d ONLN d , *!NewMessageGlobals and global data
° d ONLN d " , 8 z * Date Written: 2/1/93 ° d ONLN d 8 8 D ~ * Last reviewed: 7/2/93 ° d ONLN d N P \§ *LWhy can’t I get NewMessageGlobals to work in my gxInitialize message for my ° d ONLN d ö P§ \⁄ ( x¬ QuickDraw ° d ONLN d § \ h∞ ( Ñ 6ZGX printing extension? The global data I try to initialize isn’t being accessed correctly. ° d ONLN d ˇ h t * * ___ ° d ONLN d Ä å a *You shouldn’t ° d ONLN d Ä a å⁄ )IGcall NewMessageGlobals from any routine in which you access your global ° d ONLN dY å ò 2 ( ¥ 6data. ° d ONLN d_ å 2 ò⁄ )VOtherwise, because of optimization that your compiler may perform, the data references ° d ONLN d∂ ò § ( ¿ 63can be invalid. Instead, use an approach like this: ,
Courier
° d ONLN dÍ ∞ ª ï *extern long A5Size(void); ° d ONLN d ∫ ≈ ü *
extern void A5Init(void *); ° d ONLN d ƒ œ Æ *
typedef struct GlobalType { ° d ONLN d? Œ Ÿ § *
StringHandle aString; ° d ONLN d\ ÿ „ Y *
} GlobalType; ° d ONLN dj ‚ Ì ê *
GlobalType myGlobals; ° d ONLN dÉ ˆ N *>/* This routine sets the initial values of our global data. */ ° d ONLN d¬ Ü *
OSErr InitGlobalData() ° d ONLN dŸ
*
{ ° d ONLN d€ m *
OSErr err; ° d ONLN dÌ ) Æ *
// Initialize our globals. ° d ONLN d ( 3 *
0 myGlobals.aString = GetString(r_myStringID); ° d ONLN d=2 = Å *
err = ResError(); ° d ONLN dS< G *
0 if (!err) DetachResource(myGlobals.aString); ° d ONLN dÑF Q c *
return err; ° d ONLN dîP [ *
} ° d ONLN dñd o *0/* Our override for the gxInitialize message. */ ° d ONLN d«n y | *
OSErr MyInitialize() ° d ONLN d‹x É *
{ ° d ONLN dfiÇ ç m *
OSErr err; ° d ONLN då óN *
> // Create an A5 world, then go initialize our global data. ° d ONLN d/ñ ° *
% if (!err) err = InitGlobalData(); ° d ONLN dÜ™ µ c *
return err; ° d ONLN dñ¥ ø *
}
° d ONLN dò ÷ À *&A detailed explanation of the problem ° d ONLN dæ À÷⁄ )≥4accompanies the Kabooms printing extension sample on ° d ONLN dÛ÷ ‚ p (˛ 6the Developer CD.
° d ONLN dD Ü * Date Written: 11/17/92 ° d ONLN d\ ! ~ * Last reviewed: 7/2/93 ° d ONLN dr- 9 *.When a QuickDraw GX PostScript printer driver ° d ONLN d†-9⁄ )Í.generates a file, will it work for Level 1 and ° d ONLN dœ9 E g (a 6Level 2 printers? ° d ONLN d·E Q * * ___ ° d ONLN dÂ] i - *The ° d ONLN dÈ] -i⁄ )TLaserWriter driver bundled with QuickDraw GX produces a flavor of PostScript that we ° d ONLN d>i u + (ë 6call ° d ONLN dCi +u⁄ )Y“portable.” This flavor is meant to work on the widest range of printing devices, be they ° d ONLN dùu Å Œ (ù 6'Level 1 or 2, color or black and white. ¡ 4¡˘
. +Z-Developer Support Center ( -€September 1993 / X /
° d ONLN d ) < 8~ ( T Z-QuickDraw GX PostScript Level 2 features used
° d ONLN d . 8 < D ™ * Date Written: 11/17/92 ° d ONLN d F D < P ¢ * Last reviewed: 7/2/93 ° d ONLN d \ \ < h ⁄ *!What PostScript Level 2 features ° d ONLN d } \ ⁄ h˛ )û7does the QuickDraw GX printing mechanism take advantage ° d ONLN d µ h < t K ( ê Zof? ° d ONLN d π t < Ä N * ___ ° d ONLN d Ω å < ò ¬ *The Level 2 features used ° d ONLN d ◊ å ¬ ò˛ )Ü:in QuickDraw GX mostly have to do with patterns, text, and ° d ONLN d ò < § d ( ¿ Zbitmaps: ° d ONLN d ∞ < º @ *• ° d ONLN d ∞ E º€ ) TQuickDraw GX patterns are converted into Level 2 pattern dictionaries when going to ° d ONLN dq ∞€ º˛ ( ÿ˘a Level ° d ONLN dy º E »Ÿ ( ‰ c[2 printer. The actual PostScript code emitted by the driver differs little with respect to ° d ONLN d‘ ºŸ »˛ ( ‰˜patterns ° d ONLN d› » E ‘ ± ( cwhen going to Level ° d ONLN dÒ » ± ‘˛ )l>1 or Level 2. However, the procedures defined in the header do ° d ONLN d0 ‘ E ‡* ( ¸ c2something entirely different on a Level 2 printer. ° d ONLN dc ‡ < Ï @ ( Z• ° d ONLN de ‡ E Ï1 ) /Line layout in QuickDraw GX takes advantage of ° d ONLN dî ‡1 Ï˛ )Ï&the xshow, yshow, and xyshow operators ° d ONLN dª Ï E ¯ ” ( c when it makes sense to do so. ° d ONLN dŸ ¯ < @ ( Z• ° d ONLN d€ ¯ E ) PThe Level 2 rectangle operators are used in Level 2, though this happens in the ° d ONLN d+ ¯ ˛ ( Ë
procedures ° d ONLN d6 EÉ (, cEdefined in the header rather than in PostScript code from the driver. ° d ONLN d| < @ (8 Z• ° d ONLN d~ E Ì ) XOn Level 2 printers, the indexed color spaces are used for printing bitmaps up to eight ° d ONLN d÷Ì ˛ (8 bits ° d ONLN d€ E( _ (D cdeep. ° d ONLN d·( <4 @ (P Z• ° d ONLN d„( E4Ç ) BThe plan is to use Level 2 device-independent color when possible.
° d ONLN d&L <[~ (w Z-QuickDraw GX printer drivers and color option
° d ONLN dT[ <g ß * Date Written: 9/14/92 ° d ONLN dlg <s ¢ * Last reviewed: 7/2/93 ° d ONLN dÇ <ã ‹ * The LaserWriter driver before ° d ONLN d† ‹ã˛ )†2the QuickDraw GX version has an option to print in ° d ONLN d”ã <óØ (≥ ZIColor/Grayscale or Black & White. Why isn’t this option in the QuickDraw ° d ONLN d ãØó˛ (≥ÕGX LaserWriter ° d ONLN d+ó <£ ] (ø Zdriver? ° d ONLN d3£ <Ø N * ___ ° d ONLN d7ª <« ß *The Color/Grayscale ° d ONLN dKª ß«˛ )kAoption was added to the LaserWriter driver only for compatibility ° d ONLN dç« <”k (Ô Z?reasons. At the time, some applications couldn’t deal with the ° d ONLN dëk”˛ (Ôâ color option (specifically with ° d ONLN dÏ” <fli (˚ Z<cGrafPorts), so a Black & White mode was also provided. The ° d ONLN d(”ifl˛ (˚á Black & White mode exhibited ° d ONLN dEfl <ÎR ( Z=the same functionality as the earlier LaserWriter driver 5.2. ° d ONLN dɘ <N *4Because most applications are color compatible now, ° d ONLN d∑˜N˛ ( l the option was removed from the ° d ONLN d◊ <¨ (+ ZLQuickDraw GX printer drivers. Some people reported that the option let them ° d ONLN d#¨˛ (+ print faster when ° d ONLN d5 <b (7 Z:they chose Black & White. This was true because of quirks ° d ONLN dob˛ (7Ä!in the earlier LaserWriter driver ° d ONLN dë <'º (C ZPversion. Under QuickDraw GX, this shouldn’t be a problem. If it turns out to be ° d ONLN d·º'˛ (C⁄
a problem for ° d ONLN dÔ' <3ê (O ZFyour driver, you could incorporate black-and-white threshold printing ° d ONLN d5'ê3˛ (OÆinto your “rough draft ° d ONLN dL3 <?¢ ([ ZGmode” code. The QuickDraw GX LaserWriter driver always prints in color. ¡ X¡
